Lær at bruge SSH-tunneling til sikker surfing. Tunnelprotokoller - hvad er de? Tilgængelighedskortlægning

28. marts 2012 af Jayson Broughton
i HOW-TOs SysAdmin

"Hvis du ser et lys for enden af en tunnel, er det lyset af et tog, der nærmer sig," Robert Lowell. Endnu et godt citat. Denne artikel handler om at bygge tunneler med bruger SSH, eller som jeg kalder dette emne, "VPN-tunneler for de fattige." På trods af systemadministratorernes grundlæggende overbevisninger, kan SSH-tunneler faktisk være ganske nyttig ting for både teknikere og hjemmebrug. Jeg siger "på trods af sysadmins overbevisning", fordi omvendte tunneler eller webtrafik pakket ind i SSH kan komme igennem firewalls og indholdsfiltre. Artiklen handler dog ikke om, hvordan du kan undergrave virksomhedens sikkerhedspolitikker, men om hvordan SSH-tunneling kan gøre vores liv lidt mindre kompliceret.

Hvorfor SSH-tunneler i stedet for VPN? Ok, jeg bruger det og det derhjemme. Hvis du har fulgt mig på jaysonbroughton.com, ved du, at jeg har OpenVPN tre-faktor-autentificering (brugernavn, certifikat og engangsadgangskode) på vej. Men hvis jeg vil tjekke en af serverne under min kontrol via Android, eller kigge på en computer, hvor jeg ikke har administrative rettigheder (og den bærbare OpenVPN-klient har brug for dem), eller endda vil rette nogle fejl ved hjælp af vnc-adgang over SSH-tunnel, så er SSH mit valg af måde at sikre trafik på.

Vi vil diskutere det grundlæggende: hvordan man bygger en tunnel, hvad hver kommandosyntaks betyder, eksempler på omvendte tunneler og situationer, hvor du bør bruge en eller anden tilgang. Jeg gennemgik også kort strukturen af konfigurationsfilen.

Så åh Systemkrav. Jeg bruger Debian i virtuelt miljø, så dine resultater kan afvige fra mine. Derfor giver jeg information om værktøjerne: OpenSSH_5.3p1-serveren og OpenSSH 5.X-klienter af forskellige versioner er i brug. Inden jeg dykker ned i dybden af ssh-tunneling, må jeg sige: før du stikker hul i en virksomheds sikkerhed ved hjælp af en omvendt tunnel eller indpakning af http-trafik, skal du sørge for, at du ikke overtræder nogen stak af interne regler, såsom internetpolitikken for acceptabel brug. Det er klart, at i dette tilfælde vil systemadministratorerne straks jage dig og stege dig, især hvis du bruger en tunnel til at komme til serveren på arbejdet hjemmefra. Som systemadministrator selv får jeg stor glæde af at opdage sådanne karakterer. Tro mig, med lidt kontrol viser det sig at systemadministratorer slet ikke idioter.

Nå, ansvarsfraskrivelsen er blevet annonceret, du kan komme i gang.

At bygge SSH-tunneler er en ret simpel ting. Det kan være lidt sværere at forstå, hvad der foregår, og læremetoder. Så jeg vil give et par stykker typiske tilfælde at justere bevidstheden, før vi går videre til detaljerne i kommandoerne. Før jeg fik børn, rejste jeg en del. På mine rejser har jeg befundet mig i meget mærkelige hoteller, hvis værelser havde meget mærkelige Wi-Fi-punkter adgang. Vil du virkelig oprette forbindelse til et hoteladgangspunkt, hvis SSID er indtastet i uoversætteligt gobbledygook? Eller i lufthavnen, hvor flere åbne netværk? Når jeg er et sted i omverdenen, foretrækker jeg at tunnelere webtrafik til min rootede android via hjemmeserver. Når jeg har min bærbare computer i hænderne, åbner jeg en ssh-tunnel og omdirigerer webtrafik gennem socks5, så al trafik, der kommer til mig, er krypteret. Jeg stoler kun på åbne WAP'er i det omfang, jeg kan navigere gennem dem. Hvad ellers om simpel tekst? Jeg tunnelerer SMTP-trafik på min computer gennem min hjemmeserver, når jeg nogle steder kan se, at udgående SMTP er blokeret. Situationen er den samme med POP3. Et andet eksempel: du kan administrere X-applikationer gennem en tunnel. Du kan pakke VNC-sessioner ind i en tunnel. En af de teknikker, som jeg begyndte at bruge tidligere end andre, var omvendte tunneler. I dette tilfælde opretter du en tunnel fra en server, der er placeret bagved firewall. Når du logger ind på den SSH-server, kan du genetablere forbindelsen.

Eksempler

Før du ser på klientsiden, skal du gøre nogle ting på serversiden ved hjælp af redigering konfigurationsfil sshd.config, hvor jeg anbefaler at foretage følgende ændringer. Før du foretager ændringer, skal du kopiere den originale konfiguration for en sikkerheds skyld, hvis noget går galt.

Hvis du har foretaget ændringer, skal du genstarte sshd-serveren for at anvende dem.

Lad os gå videre til kommandolinjekontakterne.

En typisk ssh-tunnel (uden X-protokol-tunnel) ser sådan ud:

Som du måske gætter, tunnelerer -X-indstillingen X. Husk dog, at kommandoen vil tunnelere din applikation fra din fjernmaskine til din. klientmaskine med Linux. Hvis du er på Windows, skal du blot installere Cygwin/X (http://x.cygwin.com/) på din gæstebil. Jeg har ikke selv prøvet dette, men som jeg forstår burde det hjælpe med at starte ekstern X-applikation i Windows.

Når du går i gang med at etablere VNC-sessioner, skal du være forsigtig. Hvis en ekstern VNC-server kører på port 5900, skal du sørge for, at du ikke opretter forbindelse til sig selv bagefter. Selve sessionen tunneleres som i andre tilfælde ved hjælp af en gennemsigtig kommando:

Og nu har du den, en vendbar tunnel.

For klarhedens skyld gik daddoo og nerdboy4200 fra #linuxjournal sig sammen og skabte Mscgen, et program, der analyserer en sekvens af meddelelser og bygger et visuelt diagram over meddelelsesudveksling for forskellige protokoller. Det er selvfølgelig open source og ret forfærdeligt at se på (http://www.mcternan.me.uk/mscgen/). For tilfældet med en vendbar tunnel byggede de ved hjælp af deres produkt et diagram (derefter indsatte forfatteren et diagram i sin tekst, hvor intet er synligt - ca. trans.).

Konklusion

Så hvad du kan gøre med tunneling er kun begrænset af din fantasi, vi har kun givet nogle få eksempler her. Måske vil jeg i efterfølgende indlæg fortælle dig, hvordan du korrekt konfigurerer SSH på klientsiden.

Indsendt af: admin 17. oktober 2017

Sådan fungerer SSH-tunneling

En SSH-tunnel, eller SSH Port Forwarding som man(1) ssh kalder det, er en valgfri protokolfunktionalitet, der kører oven på den velkendte almindelige SSH-session. En SSH-tunnel giver dig mulighed for at sende en TCP-pakke fra den ene side af en SSH-forbindelse til den anden side og udsende IP-headeren i henhold til en forudbestemt regel under transmissionsprocessen.

Det er meget enkelt at forstå, hvordan en SSH-tunnel fungerer: hvis du forestiller dig det som en punkt-til-punkt forbindelse. Ligesom i PPP vil enhver pakke, der rammer den ene ende af forbindelsen, blive sendt og modtaget i den anden ende af tunnelen. Yderligere, afhængigt af modtageradressen angivet i IP-headeren, vil pakken enten blive behandlet af den modtagende side af tunnelen (hvis pakken er beregnet direkte til den), eller dirigeret videre ind i netværket (hvis modtageren er et andet netværk node).

Den største forskel mellem en SSH-tunnel og en PPP-forbindelse er, at kun TCP-trafik kan pakkes ind i en SSH-tunnel. (Bemærk: Der er et par hacks til at sende UDP over en TCP-socket inde i en SSH-tunnel, men den løsning er uden for denne artikels omfang.)

Den anden forskel er den i en punkt-til-punkt-forbindelse indgående trafik kan initieres fra enhver side, hvorimod det for en SSH-tunnel er nødvendigt at udtrykke "indgangspunktet" for trafikken. "Entry point" er en parameter i formularen<адрес>:<порт>, der angiver, hvilket stik der skal åbnes for at komme ind i tunnelen (fra den lokale eller fjernside af SSH-sessionen).

Ud over indgangspunktet skal du desuden angive en regel for formularen<адрес>:<порт>, ifølge hvilken headeren (mere præcist, adressen og destinationsporten) på TCP-pakken skal omskrives under transmissionen. Indgangspunktet kan indstilles fra begge ender af tunnelen. Tasterne –L (lokal) og –R (fjernbetjening) er ansvarlige for denne parameter. Med lokal og fjern mener vi tunnelens sider ud fra den oprindelige sides synspunkt, det vil sige værten, der etablerer SSH-sessionen.

Det ser lidt forvirrende ud indtil videre, så lad os se på det med et specifikt eksempel.

Direkte SSH-tunnel - giver adgang til serveren bag NAT

Alex arbejder som systemadministrator for et lille æbletærtefirma kaldet Qwerty Cakes. Hele virksomhedens netværk er placeret i ét broadcast-domæne 192.168.0.0/24. Bruges til at få adgang til internettet software router baseret på Linux, hvis adresse er 192.168.0.1 på virksomhedens netværksside og 1.1.1.1 på internetsiden. OpenSSD-dæmonen er oppe og køre på routeren, som er tilgængelig via socket 1.1.1.1:22. Inde i netværket, en intern virksomhedsportal, hvor Alex skal foretage ændringer til i morgen tidlig Webgrænseflade. Alex ønsker dog ikke at blive sent på arbejde, han vil have adgang til portalen hjemmefra fra sin egen hjemmecomputer med adresse 2.2.2.2.

Alex kommer hjem og etablerer efter middagen følgende forbindelse til virksomhedens router:

Hvad skete der? Alex etablerede en SSH-session mellem adresserne 2.2.2.2 og 1.1.1.1, mens han åbnede et lokalt "indgangspunkt" til tunnelen 127.0.0.1:8080 på sin hjemmecomputer:

alex@Alex-PC:~$ sudo lsof -nPi | grep 8080

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (LYT)

Enhver TCP-pakke, der kommer ind i socket 127.0.0.1:8080 fra Alex's computer, vil blive sendt over en punkt-til-punkt-forbindelse indeni SSH sessioner, i dette tilfælde vil destinationsadressen i TCP-headeren blive omskrevet fra 127.0.0.1 til 192.168.0.2, og porten fra 8080 til 80.

Nu, for at komme til sin virksomheds portal, behøver Alex kun at skrive i browseren:

Hvordan går de netværkspakker inde i en SSH-tunnel

Lad os se nærmere på, hvad der skete med TCP-pakken, da den passerede gennem SSH-tunnelen:

1. En TCP-pakke med kildeadresse 127.0.0.1 og destinationsadresse og port 127.0.0.1:8080 indtastet socket 127.0.0.1:8080, åbnes efter proces ssh;

2. ssh-processen modtog pakken i overensstemmelse med oversættelsesreglen, omskrev destinationsadressen og porten til 192.168.0.2:80 og sendte den inden for SSH-sessionen til den eksterne part 1.1.1.1;

3. sshd-processen på router 1.1.1.1 modtog pakken og efter at have set på destinationsadressen sendte den til vært 192.168.0.2, mens kildeadressen blev omskrevet fra 127.0.0.1 til adressen på dens egen grænseflade 192.168.0.1, således at modtageren, som ikke ved noget om eksistensen af en SSH-tunnel, returnerede pakken til routeren og ikke sendte den til sin egen localhost 127.0.0.1.

alex@Alex-PC:~$ ssh -L

127.0.0.1:8080:192.0.0.2:80 [e-mail beskyttet]

I i dette eksempel, hvis portalen eller en anden ressource, som Alex skal have adgang til, var placeret på selve routeren (for eksempel på 192.168.0.1:80), så ville kommandoen se sådan ud:

Hvis tjenesten er tilgængelig hos localhost (for eksempel en lokal SQL-server), så kan du få adgang til den:

alex@Alex-PC:~$ ssh -L

127.0.0.1:13306:127.0.0.1:3306 [e-mail beskyttet]

Konstruktioner som -L 127.0.0.1:80:127.0.0.1:80 kan se ret mærkelige ud ved første øjekast. Men der er ikke noget kompliceret ved dem, hvis du husker, at beslutningen om pakkerouting træffes på den fjerne side af tunnelen. Du skal huske den grundlæggende regel: andet par<адрес>:<порт>behandlet af den fjerne side af tunnelen.

Derfor vil en pakke med destinationsadressen 127.0.0.1 i oversættelsesreglen blive behandlet af den anden side af SSH-sessionen og intet andet.

Som du sikkert allerede har gættet, kan tunnelindgangspunktet oprettes ikke kun på loopback-grænsefladen. Hvis tunnelen skal gøres tilgængelig ikke kun for den lokale vært, men også for andre netværksdeltagere, så kan du angive rigtige adresse interface.

alex@Alex-PC:~$ ssh -L

10.0.0.5:8080:192.0.0.2:80 [e-mail beskyttet]

Alex's computer Alex-PC har to netværksgrænseflade med adresser 2.2.2.2 og 10.0.0.5. Under sessionsetableringsprocessen vil ssh åbne socket 10.0.0.5:8080 på Alex-PC-computeren. Alex kan nu få adgang til portal 192.168.0.2:80 fra sin bærbare computer med adresse 10.0.0.4 og alle hans hjemmenetværk 10.0.0.0/24.

Omvendt SSH-tunnel - udsæt dine ressourcer til internettet

Som jeg allerede har sagt, kan tunnelindgangspunktet åbnes ikke kun fra siden af ssh-sessionens ophavsmand, men også fra den eksterne side, det vil sige fra den, som vi etablerer en ssh-session til. For at gøre dette skal du bruge indstillingen -R i stedet for indstillingen -L. Hvad er det for?

For eksempel for at kunne udgive en lokal service til fjernadgang.

Internettet kører på Alexs bærbare computer apache server tilgængelig på 127.0.0.1 med en testkopi af virksomhedsportalen. Alex skal have adgang til Webserver til dine kolleger for at teste grænsefladen. Generelt til sådanne formål ville det være rart for Alex at implementere en mere pålidelig testsandkasse. Men da vores Alex ikke er mere end en virtuel karakter i denne artikel, for at demonstrere driften af SSH-tunnelen, etablerer han en session mellem sin bærbare computer og Linux-routeren. Og ved hjælp af parameteren -R åbnes port 8080 på routerens interne grænseflade med adressen 192.168.0.1, som refererer til socket 127.0.0.1:80 på dens testwebserver.

Som du kan se, åbnede sshd-processen lokal socket 8080 på routeren

alex@Router:~$

sudo lsof -nPi | grep 8080

sshd

17233 alex 9u IPv4

95930 0t0 TCP 192.168.0.1:8080 (LYT)

Lad os se, hvad der sker med en TCP-pakke sendt fra computer 192.168.0.200 mod en testportal offentliggjort den 192.168.0.1:8080:

1. En TCP-pakke med en kildeadresse på 192.168.0.200 og en destinationsadresse og port på 192.168.0.1:8080 vil ende på socket 192.168.0.1:8080, åbnet af sshd-processen;

2. sshd-processen, efter at have modtaget pakken, i overensstemmelse med oversættelsesreglen, vil omskrive destinationsadressen og porten fra 192.168.0.1:8080 til 127.0.0.1:80 og sende den inden for SSH-sessionen til den oprindelige part 2.2. 2,2;

3. ssh-processen på Alex's bærbare computer, efter at have modtaget pakken og set dens destinationsadresse, vil omskrive afsenderadressen fra 192.168.0.200 til dens loopback-adresse og sende den til den lokale socket 127.0.0.1:80, åbnet af apache behandle.

En vigtig note, som jeg efterlod til slutningen af artiklen.

Hvis der, når der åbnes et tunnelindgangspunkt, bruges localhost i stedet for adressen på den rigtige grænseflade, så kan den udelades og dermed forkorte kommandoen med

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [e-mail beskyttet]

Før

alex@Alex-PC:~ssh -L

8080:192.0.0.1:80 [e-mail beskyttet]

Det her vigtig egenskab syntaks vil være nyttig for os i det følgende eksempel.

Dobbelt tunnelering

Lad os se lidt mere på komplekst eksempel. En SQL-Tester bruger placeret bag NAT skal have adgang til databasen på SQL server, som også står bag NAT. SQL-Tester kan ikke oprette forbindelse direkte til serveren, da der ikke er nogen tilsvarende oversættelser i NAT-servernetværket. Men fra begge værter kan du etablere en SSH-session med den mellemliggende server 3.3.3.3.

Installer fra SQL server SSH forbindelse med server 3.3.3.3 og åben port 13306 på loopback-grænsefladen på server 3.3.3.3, som refererer til den lokale SQL-tjeneste, der kører på den lokale socket 127.0.0.1:3306 på SQL-serveren:

dbuser@SQL-server:~$ ssh -R 13306:127.0.0.1:3306

[e-mail beskyttet]

Nu, fra SQL-Tester-klientværten, etablerer vi en forbindelse med 3.3.3.3 og åbner port 3306 på klientens loopback-grænseflade, som igen refererer til 127.0.0.1:13306 på server 3.3.3.3, som... henviser til 127.0.0.1:3306 på SQL-serveren. Det er simpelt.

tester@SQL-Tester:~$ ssh -L

3306:127.0.0.1:13306 [e-mail beskyttet]

Dynamisk tunnel - SSH som Socks proxy

I modsætning til tunneler med eksplicit angivelse af oversættelsesregler, fungerer en dynamisk tunnel efter et helt andet princip. I stedet for at angive en en-til-en adresse:port-mapping for hver destinationsadresse og port, åbner du en socket på den lokale side af SSH-sessionen, som gør din vært til en SOCKS4/SOCKS5-proxyserver. Lad os se

Eksempel:

Opret en dynamisk tunnel socket 127.0.0.1:5555 på klientværten i en SSH-session til server 2.2.2.2

bruger@klient:~$ ssh -D 5555 [e-mail beskyttet]

Tjek at porten er åben

bruger@klient:~$ sudo lsof -nPi | grep 5555

7284 bruger 7u

IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (LYT)

Og vi registrerer proxyen i indstillingerne for browseren eller enhver anden software, der understøtter SOCKS proxy.

Nu vil al browsertrafik gå gennem SOCKS-proxyen inde i en krypteret SSH-forbindelse mellem værterne 1.1.1.1 og 2.2.2.2.

Hvordan bruger man SSH på Microsoft Windows?

Efter at have læst artiklen kan du beslutte, at alle fordelene ved SSH-tunneler kun er tilgængelige for brugere af Unix-lignende systemer. Det er det dog ikke. Næsten alle terminalklienter til Windows, der kører over SSH-protokollen, har tunneling-understøttelse.

I nogen tid nu har det været muligt at bruge Windows ikke kun som SSH klient. Det er muligt at installere en SSH-server på Windows.

Hvornår skal man bruge SSH-tunneler?

For at skabe permanente tunneler på kampservere skal du selvfølgelig bruge en speciel software. Men for hurtig løsning opgaver med port forwarding, fejlfinding, opnåelse af hurtig fjernadgang og løsninger generelt specifik opgave"her og nu" er brugen af SSH-tunneler ofte en god hjælp.

Med deres hjælp kan du bygge hele netværk, tunneler i tunneler og kombinere typer af tunneler. Dette kan give dig mulighed for hurtigt at få adgang til steder, der ser ud til at være umulige at komme til.

Ud over dens hovedfunktion giver SSH-protokollen administratoren en masse nyttige værktøjer, i denne artikel vil vi tale om at skabe VPN-tunnel ved hjælp af SSH.
SSH tunneling- den enkleste og hurtig måde få en tunnel til Linux-serveren, fordi OpenSSH-pakken er højst sandsynligt allerede installeret på den, og den resulterende tunnel vil ikke have problemer med NAT.

Sådan en tunnel er enkel, men ikke pålidelig, fordi bruger en TCP-forbindelse og indeholder ikke indbyggede mekanismer til at genoprette en forbindelse efter en pause.
SSH tunnel bedst brugt til test(hvis du f.eks. skal sende UDP-pakker til en fjernserver, hjælper portvideresendelse via SSH ikke i dette tilfælde), og til permanente tunneler skal du bruge protokoller, der er specielt designet til dette, såsom OpenVPN, PPTP, L2TP, IPSec, GRE osv. .d. (Alle kommandoeksempler i artiklen er korrekte for CentOS 6)

Installation og konfiguration

Installer OpenSSH-pakken fra lagrene, hvis den ikke allerede er installeret:

yum installer openssh openssh-server openssh-klienter

For at serveren tillader brugen af tunneler, skal du aktivere PermitTunnel-indstillingen i OpenSSH-serverindstillingsfilen (normalt /etc/ssh/sshd_config) og genstarte OpenSSH-serveren (service sshd genstart).

PermitTunnel ja

I slutningen af serverindstillingsfilen kan der være indstillingssektioner for specifikke værter, brugere, brugergrupper osv.
Lignende sektioner begynder med linjerne

Vært...
eller
Match...

PermitTunnel-muligheden skal tilføjes før de beskrevne sektioner.

Brug af SSH-tunneler

Til alle eksempler vil OpenSSH-serveren tilgængelig på 192.168.1.100 blive brugt.

Simpel SSH-tunnel

For at oprette den enkleste SSH-tunnel kan du køre kommandoen

sudo ssh -w 7:7 -l root 192.168.1.100

Optionen er ansvarlig for at skabe en tunnel

W<номер_локального_интерфейса>:<номер_удалённого_интерфейса>

I stedet for det lokale og/eller fjerngrænsefladenummer kan du bruge værdien "any", så vil den næste ledige TUN-grænseflade blive oprettet.

Efter at have bestået sudo- og SSH-godkendelse på de lokale og eksterne værter, skulle en deaktiveret tun7-grænseflade vises.

For at bruge tunnelen skal du aktivere grænsefladerne og konfigurere dem med IP-adresser fra det samme undernet, for eksempel sådan:

# på localhost
# på fjernværten

Nu vil den lokale vært have adgang til den eksterne vært på 10.255.255.1 via en krypteret tunnel (forudsat at firewalls på de lokale og eksterne værter tillader disse forbindelser).

Den store ulempe ved denne ordning er behovet for adgang til en ekstern server via SSH med superbrugerrettigheder (da der kræves superbrugerrettigheder for at oprette en TUN-grænseflade), mens mange systemadministratorer foretrækker at nægte root-adgang via SSH for større sikkerhed. Eliminering af denne ulempe er beskrevet i næste afsnit.

SSH-tunnel med uprivilegerede brugerrettigheder

For at oprette en SSH-tunnel med en uprivilegeret brugers rettigheder, skal du først oprette en TUN-grænseflade, der tilhører denne bruger (for at oprette en TUN-grænseflade skal du under alle omstændigheder have superbrugerrettigheder på fjernværten).
For at skabe en TUN-grænseflade i ældre Linux distributioner tunctl-værktøjet bruges (skal være tilgængeligt fra distributionslagrene), i nyere distributioner er denne funktionalitet inkluderet i iproute2-pakken. For at bestemme, hvordan du opretter en TUN-grænseflade på din vært, skal du køre kommandoen

Hvis kommandoen giver en fejl

Objektet "tuntap" er ukendt, prøv "ip help".

Det betyder, at du skal bruge tunctl-værktøjet, efter at have installeret det tidligere (yum install tunctl), ellers skulle kommandoen returnere en liste over TUN/TAP-grænseflader på værten.

Lad os gå videre til opsætningen.

Opret en uprivilegeret bruger på fjernværten:

useradd ssh_tunnel

Opret en TUN-grænseflade, der tilhører denne bruger

Brug af tunctl:

tunctl -n -t tun7 -u ssh_tunnel -g ssh_tunnel

Brug af iproute2:

ip tuntap tilføj dev tun7 mode tun bruger ssh_tunnel gruppe ssh_tunnel

Tilslutning af en SSH-tunnel ligner det forrige eksempel:

# på localhost
sudo ssh -w 7:7 -l ssh_tunnel 192.168.1.100
ifconfig tun7 op 10.255.255.2 pointopoint 10.255.255.1
# på fjernværten
ifconfig tun7 op 10.255.255.1 pointopoint 10.255.255.2

Oprettelse af en bruger kun til SSH-tunneling

I på dette tidspunkt Det vil blive overvejet at forhindre en uprivilegeret bruger i at bruge konsollen og samtidig tillade SSH-tunneling for den pågældende bruger. Det vil ikke fungere at indstille shell "/bin/false" eller "/sbin/nologin" for brugeren, fordi i dette tilfælde vil brugeren slet ikke være i stand til at etablere en SSH-forbindelse.

For at indtaste de beskrevne begrænsninger skal du tilføje følgende linjer til slutningen af OpenSSH-serverindstillingsfilen (/etc/ssh/sshd_config) og genstarte OpenSSH-serveren (service sshd genstart)

Match bruger ssh_tunnel
X11Vid.nr
TilladTcpForwarding ja
AllowAgentForwarding nr
GatewayPorts nr
ForceCommand echo "Denne konto kan kun bruges til tunneling"; kat

Begrænsningen i dette eksempel er pålagt den tidligere oprettede bruger ssh_tunnel. ForceCommand-parameteren får brugeren til automatisk at udføre kommandoen "echo "Denne konto kan kun bruges til tunneling"; kat" umiddelbart efter tilslutning. Dette vil forhindre brugeren i at bruge konsollen normalt, for hvis katteprocessen afbrydes ved at trykke på Ctrl+C, vil SSH-forbindelsen blive lukket.

SSH-tunneling kan hjælpe ikke kun i sager, hvor det er nødvendigt at transmittere ukrypteret trafik over en krypteret forbindelse, men også når du ikke har adgang til en ressource på netværket, men adgang er nødvendig.

Lad os se på oprettelse og opsætning af flere muligheder.

Og så har vi en server, lad os kalde det vært-1. Til ham har vi fuld adgang kun ved SSH- men vi skal åbne Tomcat, der opererer på port 8082 - hvortil de ikke kan slippe os igennem.

Vi vil overveje muligheden med indstilling Windows Og Kitt.

Åbning SSH- forbindelse til til den ønskede server, lad os logge ind.

Vi angiver følgende parametre:

Kildeport: enhver ubrugt port på dit system;
Destinationshavn: 127.0.0.1:8082

Klik Tilføje, Derefter ansøge.

Gå til browserindstillingerne og indstil proxy-parametrene:

Nu er der kun tilbage at åbne siden http://localhost:3002 i browseren - så kommer vi til siden Tomcat på serveren vært-1.

Hvis tunnelen ikke fungerer, skal du kontrollere på serveren, om pakkevideresendelse er aktiveret. I filen /etc/ssh/sshd_config skal du finde og fjerne linjen:

TilladTcpForwarding ja

Og genstarter SSHd:

# service sshd genstart Stop sshd: [ OK ] Starter sshd: [ OK ]

Et andet eksempel - vi har den samme eksterne server, hvorfra vi har normal adgang til alle ressourcer på internettet. Men fra arbejdspladsen har vi adgang til og er lukket.

Vi udfører lignende handlinger, men med mindre forskelle. Indstillinger i Kitt:

Kildeport - forlad det samme, men i stedet Lokal- vælg Dynamisk. Klik Tilføje, ansøge.

Lad os gå til browserindstillingerne:

Bemærk venligst, at proxy-typen her ikke er HTTP, men SOCKS.

Nyd adgangen til dine yndlingssider.

Og en mere interessant sag.

Vi har det samme vært-1. Ud over det er der en anden server, lad os kalde det vært-2. Derudover har vi en maskine med Windows, som skal have adgang til ressourcen TeamCity på serveren vært-1 på port 8111. I dette tilfælde adgang fra Windows-vi har kun maskiner til serveren vært-2, og kun til port 22.

Til at begynde med hæver vi tunnelen mellem vært-1 Og vært-2. Vi fortsætter vært-1:

$ ssh -f -N -R host-2:8082:localhost:8111 brugernavn@host-2

Så vi åbner en tunnel, som lokalt (på vært-1) ser på port 8111, og på den anden side er maskinen vært-2, hvor port 8082 åbner og venter på indgående forbindelser. Når du modtager pakker på port 8082 (og kun via lo0-grænsefladen! dette er vigtigt) - vil det omdirigere dem til maskinen vært-1 port 8111.

Med hensyn til lo0-grænsefladen. Når den er installeret SSH-tunnel, selv når maskinens eksterne IP specificeres - forbindelsen er kun rejst fra localhost, dvs. 127.0.0.1.

Lad os se på vært-2:

$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* LYT -

For at ændre dette, skal du redigere sshd daemon-konfigurationsfilen - /etc/ssh/sshd_config og ændre parameteren:

#GatewayPorts nr

Men det gør vi ikke nu, det er kun en note.

Lad os fortsætte. Lad os gå videre til opsætningen Kitt På vores Windows-bil. Alt er enkelt her - vi bruger eksempel 1 fra denne artikel, bare skift porten til den ønskede (i skærmbilledet er den der forresten). Lad os forbinde Kitt til værten vært-2, Opsætning tunnel. Skift indstillinger i browseren proxy- og vi får, hvad vi har brug for, angiv adressen http://localhost:3002:

SSH er ret følsom over for pakketab, så tunneler kan ofte droppes.

For at undgå dette kan du enten lege med parametrene i sshd-indstillingsfilen - /etc/ssh/sshd_config:

#TCPKeepAlive ja #ServerAliveInterval #ServerAliveCountMax

Eller brug autossh-værktøjet.

Fra redaktøren af AnswIT:

I dette eksempel, hvis portalen eller en anden ressource, som Alex havde brug for at få adgang til, var placeret på selve routeren (for eksempel på 192.168.0.1:80), så ville kommandoen se sådan ud:

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [e-mail beskyttet]

Hvis tjenesten er tilgængelig hos localhost (f.eks. en lokal SQL-server), så få adgang til den
kan tilgås:

alex@Alex-PC:~$ ssh -L
127.0.0.1:13306:127.0.0.1:3306 [e-mail beskyttet]

Konstruktioner som -L 127.0.0.1:80:127.0.0.1:80 kan se ret mærkelige ud ved første øjekast. Men der er ikke noget kompliceret ved dem, hvis du husker, at beslutningen om at
routing af pakken modtages på den fjerne side af tunnelen. Du skal huske den grundlæggende regel: andet par
<адрес>:<порт>behandlet af den fjerne side af tunnelen.
Derfor vil en pakke med destinationsadressen 127.0.0.1 i oversættelsesreglen blive behandlet af den anden side af SSH-sessionen og intet andet.

alex@Alex-PC:~$ ssh -L
10.0.0.5:8080:192.0.0.2:80 [e-mail beskyttet]

Alex's computer Alex-PC har to netværksgrænseflader med adresser 2.2.2.2 og 10.0.0.5. Under sessionsetableringsprocessen vil ssh åbne socket 10.0.0.5:8080 på Alex-PC-computeren. Nu kan Alex få adgang til portalen 192.168.0.2:80 fra sin bærbare computer med adressen 10.0.0.4 og fra alle
dit hjemmenetværk 10.0.0.0/24.

Omvendt SSH-tunnel - udsæt dine ressourcer til internettet

Apache-webserveren kører på Alexs bærbare computer og er tilgængelig
på 127.0.0.1 med en testkopi af virksomhedsportalen. Alex skal give adgang til sin webserver
kolleger til at teste grænsefladen. Generelt til sådanne formål ville det være rart for Alex at implementere en mere pålidelig testsandkasse. Men da vores Alex ikke er mere end en virtuel karakter i denne artikel, er han
demonstration af, hvordan SSH-tunnelen fungerer
session mellem din bærbare computer og Linux-router. Og ved at bruge parameteren -R åbnes port 8080 til
routerens interne grænseflade med adressen 192.168.0.1, som refererer til socket 127.0.0.1:80 på dens testwebserver.

Som du kan se, åbnede sshd-processen lokal socket 8080 på routeren

alex@Router:~$
sudo lsof -nPi | grep 8080

sshd
17233 alex 9u IPv4
95930 0t0 TCP 192.168.0.1:8080 (LYT)

Lad os se, hvad der sker med en TCP-pakke sendt fra computer 192.168.0.200 mod en testportal offentliggjort den 192.168.0.1:8080:
1. En TCP-pakke med en kildeadresse på 192.168.0.200 og en destinationsadresse og port på 192.168.0.1:8080 vil ende på socket 192.168.0.1:8080, åbnet af sshd-processen;

Som du kan se, er udsendelsesreglerne meget enkle. Værten, der åbner stikket til tunnelen, oversætter destinationsadressen og porten i henhold til oversættelsesreglen. Værten på den modsatte side af tunnelen ændrer kildeadressen og porten i henhold til dens routingtabel. Rutetabellen er nødvendig for det første for at sende pakken i den rigtige retning, og for det andet for at producere
at erstatte kildeadressen med adressen på den grænseflade, hvorfra pakken vil blive sendt.
En vigtig bemærkning, som jeg efterlod i slutningen af artiklen.
Hvis der, når der åbnes et tunnelindgangspunkt, bruges localhost i stedet for adressen på den rigtige grænseflade, så kan den udelades og dermed forkorte kommandoen med

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [e-mail beskyttet]

alex@Alex-PC:~ssh -L
8080:192.0.0.1:80 [e-mail beskyttet]

Denne vigtige syntaksfunktion vil være nyttig i det følgende eksempel.

Dobbelt tunnelering

Lad os se på et lidt mere komplekst eksempel. En SQL-Tester-bruger placeret bag NAT skal have adgang til databasen på en SQL-server, som også er placeret bag NAT. SQL Tester kan ikke installere
forbindelse direkte til serveren, da der ikke er nogen tilsvarende oversættelser i NAT-servernetværket. Du kan dog etablere en SSH-session fra begge værter med en mellemliggende
server 3.3.3.3.

Fra SQL-serveren etablerer vi en SSH-forbindelse til server 3.3.3.3 og åbner den på serverens loopback-grænseflade
3.3.3.3 port 13306, der henviser til den lokale SQL-tjeneste, der kører på den lokale socket 127.0.0.1:3306 på SQL-serveren:

dbuser@SQL-server:~$ ssh -R 13306:127.0.0.1:3306
[e-mail beskyttet]

Nu, fra SQL-Tester-klientværten, etablerer vi en forbindelse til 3.3.3.3 og åbner port 3306 på klientens loopback-grænseflade, som igen refererer til 127.0.0.1:13306 på serveren
3.3.3.3, som... henviser til 127.0.0.1:3306 på SQL-serveren. Det er simpelt J

tester@SQL-Tester:~$ ssh -L
3306:127.0.0.1:13306 [e-mail beskyttet]

Dynamisk tunnel - SSH som Socks proxy

I modsætning til tunneler med eksplicit angivelse af oversættelsesregler, fungerer en dynamisk tunnel efter et helt andet princip. I stedet for at angive en en-til-en adresse:port-tilknytning for hver destinationsadresse og port, kan du
Åbn en socket på den lokale side af SSH-sessionen, som gør din vært til en proxyserver, der kører ved hjælp af SOCKS4/SOCKS5-protokollen. Lad os se
eksempel:

Opret en dynamisk tunnel socket 127.0.0.1:5555 på klientværten i en SSH-session til server 2.2.2.2

bruger@klient:~$ ssh -D 5555 [e-mail beskyttet]

Tjek at porten er åben

bruger@klient:~$ sudo lsof -nPi | grep 5555

ssh
7284 bruger 7u
IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (LYT)

Og vi registrerer en proxy i indstillingerne for browseren eller evt
anden software, der understøtter SOCKS proxyer.

Nu vil al browsertrafik gå gennem en SOCKS-proxy inde i en krypteret SSH-forbindelse
mellem værter 1.1.1.1 og 2.2.2.2.

Hvordan bruger man SSH på Microsoft Windows?

Efter at have læst artiklen kan du beslutte, at alle fordelene ved SSH-tunneler kun er tilgængelige
brugere af Unix-lignende systemer. Det er det dog ikke. Næsten alt for Windows, der bruger SSH-protokollen, har tunneling-understøttelse.

I et stykke tid har det været muligt at bruge Windows som mere end blot en SSH-klient. Jeg har en mulighed.

Hvornår skal man bruge SSH-tunneler?

For at skabe permanente tunneler på kampservere skal du selvfølgelig bruge speciel software. Men for hurtigt at løse problemet med port forwarding, fejlfinding, få hurtig fjernadgang og generelt løse et specifikt problem "her og nu", er brugen af SSH-tunneler ofte en god hjælp.