Hlavní navigace

Stavíme tunely v OpenSSH

Ondřej Caletka

V minulém díle našeho seriálu o zajímavých vlastnostech OpenSSH jsme si představili způsob, jak se snadno přihlašovat ke vzdáleným serverům bez nutnosti vypisovat pokaždé heslo. Dnes se společně podíváme na to, jak je možné pomocí OpenSSH stavět bezpečné tunely pro libovolné síťové protokoly.

Přesměrování agenta

Použití SSH agenta, které jsme si ukázali v minulém díle, v sobě skrývá ještě jednu zajímavou vlastnost. Vzhledem k tomu, že veškerá komunikace s ním probíhá přes jeden UNIXový soket, není problém tento soket samotným protokolem SSH tunelovat a nosit si ho s sebou, zatímco cestujeme mezi servery. Tato funkce se zapíná parametrem -A příkazu ssh. SSH server vytvoří na vzdálené straně soket s příslušnými právy a veškerý provoz z a do tohoto soketu přenese přes SSH spojení na klienta, který jej nasměruje do soketu skutečného agenta. Server také správně nastaví proměnnou SSH_AUTH_SOCK, takže z pohledu uživatele je přesměrovaný agent zcela shodný s lokálně běžícím agentem. Protože soket slouží nejen k podepisování, ale i pro ukládání klíčů, můžeme dokonce do svého lokálního agenta přidat vzdálený klíč:

user@stanice:$ ssh-add -l
1024 ab:9e:90:46:b9:fd:94:ae:fd:51:9c:cb:d1:fa:34:29 /home/user/.ssh/id_dsa (DSA)
user@stanice:$ ssh -A server.example.com
user@server:$ ssh-add -l
1024 ab:9e:90:46:b9:fd:94:ae:fd:51:9c:cb:d1:fa:34:29 /home/user/.ssh/id_dsa (DSA)
user@server:$ ssh-add
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
user@server:$ logout
Connection to server.example.com closed.
user@stanice:$ ssh-add -l
1024 ab:9e:90:46:b9:fd:94:ae:fd:51:9c:cb:d1:fa:34:29 /home/user/.ssh/id_dsa (DSA)
2048 50:b2:f0:44:c9:10:f2:0b:f6:00:38:0c:b1:cd:e7:35 /home/user/.ssh/id_rsa (RSA)

Povšimněte si, že v lokálním agentovi máme nyní uložené dva klíče a to i přesto, že spojení k serveru, na kterém je uložen druhý klíč, bylo už dávno přerušeno.

Funkce přesměrování agenta je z bezpečnostních důvodů ve výchozím nastavení vypnuta. Vzhledem k tomu, že ssh-agent promptně podepíše cokoli komukoli s právem pro zápis do příslušného soketu, znamená to, že uživatel root může kdykoli zneužit SSH agenta kteréhokoli lokálního uživatele. Při přesměrování agenta to samé platí o superuživatelích vzdálených serverů. Přesměrování bychom tedy měli používat jen na stroje, u kterých máme důvěru k jejich správci.

Tunelování protokolu X11

Úplně stejný princip funguje při tunelování protokolu X11, pomocí kterého je možné snadno spouštět vzdálené grafické aplikace. Slouží k tomu přepínač -X, pokud by nefungoval, můžete zkusit použít -Y. Nejprve je však potřeba povolit takové přesměrování v konfiguračním souboru serveru (/etc/ssh/sshd_c­onfig). Přesměrování protokolu X11 s sebou totiž nese poměrně značná rizika – každý X-klient obvykle může číst obsah kteréhokoli okna na obrazovce, stejně jako stisknuté klávesy a kliknutí myši. Aby to neměl případný útočník tak lehké, musí překonat několik překážek:

  • Vzdálený soket je svázán s loopback adresou 127.0.0.1. Útočící software tedy musí běžet na stejném počítači, jako SSH server. To ale není překážka, útočník může požadavky na SSH server protunelovat (třeba pomocí SSH).
  • Přístup k X serveru je chráněn autentizačním řetězcem (cookie), který je uložen v souboru ~/.Xauthority, čitelném pouze majiteli. SSH server automaticky vloží cookie do vzdáleného souboru, takže pro uživatele je přístup k X serveru přes tunel zcela transparentní. Útočník tedy musí buď nějakým způsobem vyčíst cookie ze souboru (což může jen superuživatel vzdáleného serveru), nebo spoléhat na to, že klient ochranu serveru pomocí cookie vypnul. Například spousta návodů k odstraňování problémů s X servery radí vyzkoušet příkaz xhost +, který právě tuto ochranu vyřazuje z činnosti.
  • X Server může podporovat tzv. bezpečný režim. To znamená, že přesměrovaným klientům povolí pouze omezenou množinu operací, zakáže tedy například čtení obsahu cizích oken nebo získávání úhozů kláves, které patří jinému oknu. Tento bezpečnější režim funguje dobře s dostatečně čerstvým Xorg a OpenSSH, použitím přepínače -X. Není-li však do X serveru podpora bezpečného režimu zakompilována, použití přepínače -X selže a uživateli nezbývá, než použít přepínač -Y. Při jeho použití jsou i vzdálení X-klienti považováni za důvěryhodné a bezpečný režim není použit.

Dynamické tunelování

O statickém tunelování, pomocí přepínačů -L a -R se zde na Rootu už minimálně jednou psalo. Dovolíme si tedy problematiku přeskočit a podívat se rovnou na dynamické tunelování:

$ ssh -D1080 user@server 

Tímto jednoduchým příkazem jsme z SSH klienta vyrobili SOCKS proxy server. Všechny požadavky o spojení, které SOCKS server obdrží, protuneluje SSH protokolem a vyřídí na straně SSH serveru. Stačí tedy v aplikaci, jako je webový prohlížeč nebo poštovní klient, nastavit použití SOCKS proxy serveru (verze 5 nebo 4) s adresou localhost:1080. Od té chvíle bude veškerý provoz směrován tunelem. Jak snadné.

Dynamické tunelování je možné použít i v případě, že daná aplikace nemá podporu pro SOCKS proxy. Slouží k tomu utilitka tsocks, která obaluje volání systémové funkce connect(). Nejprve nastavíme konfigurační soubor /etc/socks/tsoc­ks.conf:

# Na lokální sítě chceme přistupovat přímo
local = 192.168.0.0/255.255.0.0
local = 172.16.0.0/255.240.0.0
local = 10.0.0.0/255.0.0.0

# IP adresa, port a verze SOCKS serveru
server = 127.0.0.1
server_port = 1080
server_type = 5

#tunelování DNS dotazu SSH SOCKS serverem nefunguje
tordns_enable = no

Pak už stačí danou aplikaci spustit s prefixem tsocks, například:

$ tsocks wget http://www.whatismyipv6.net -O out.html

OpenSSH jako VPN

OpenSSH jde v tunelovacích možnostech ještě dál – nabízí možnost vytvoření plnohodnotné virtuální privátní sítě prostřednictvím univerzálních síťových rozhraní TUN/TAP. Potřebné ingredience:

  • Rootovský přístup na oba stroje.
  • Povoleno vytváření tunelu v konfiguračním souboru serveru – volba PermitTunnel.
  • Ovladač pro Universal TUN/TAP device, který je součástí jádra. O tom, že je zaveden, se přesvědčíme kontrolou existence souboru /dev/net/tun.

Jsou-li všechny podmínky splněny, nastartujeme tunel pomocí:

# ssh -w 1:1 root@server

Pokud šlo všechno dobře, objevila se na obou koncích tunelu síťová zařízení tun1, která jsou vzájemně spojena SSH tunelem. Je na nás, abychom rozhraní nahodili (ip link set dev tun1 up), nastavili příslušné IP adresy a směrování. Na vzdálené straně k tomuto účelu můžeme připravit skript, který necháme příkazem ssh spustit jednoduše tak, že jeho název napíšeme na konec příkazového řádku:

# ssh -w 1:1 root@server setuptunnel.sh

V některém z příštích dílů seriálu si ukážeme, jak takový tunel zabezpečit, aby uživatel, který jej chce navazovat, neměl zároveň možnost využívat rootovský shell na straně SSH serveru.

SSH bez shellu

Při stavění všemožných ssh tunelů se často může stát, že vlastní terminálové spojení na vzdálený počítač je nežádoucí, nadbytečné. V takovém případě s výhodou využijeme volbu -N, která zabrání spuštění shellu. Obvykle se vyplatí v kombinaci s přepínačem -f, který přenese klienta na pozadí po dokončení autentizace.

Chceme-li určitý tunel udržovat permanentně v provozu, může se hodit utilitka autossh, která SSH klienta hlídá a automaticky restartuje v případě potřeby.

Obsah příští části

Příště znovu otevřeme problematiku prokazování identity. Podíváme se na serverové klíče a možnosti jejich ověřování. Ukážeme si, jak k takovému účelu použít systém DNSSEC.

Našli jste v článku chybu?

8. 6. 2011 8:50

misch (neregistrovaný)

Nepomohlo by jen "ssh -o ServerAliveIn­terval=60"? Pak se o pravidelné posílání keepalive paketů přes tunel postará SSHčko samo.

12. 6. 2011 8:10

Snad kazda VPN pouziva tun i OpenVPN. Pokud bylo tim "klient-server" mysleno to, ze klient bude mit pristup nejen na VPN server, ale i do siti k nimz je pripojenej, tak to je pouze otazka nastaveni routovani a NAT. Jinak SSH je vzdy z podstaty klient-server architektura, ktezto OpenVPN bylo zpocatku pouze 1:1.

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Lupa.cz: Kdo pochopí vtip, může jít do ČT vyvíjet weby

Kdo pochopí vtip, může jít do ČT vyvíjet weby

DigiZone.cz: „Black Friday 2016“: závěrečné zhodnocení

„Black Friday 2016“: závěrečné zhodnocení

120na80.cz: Co všechno ovlivňuje ženskou plodnost?

Co všechno ovlivňuje ženskou plodnost?

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

Lupa.cz: Propustili je z Avastu, už po nich sahá ESET

Propustili je z Avastu, už po nich sahá ESET

Podnikatel.cz: Snížení DPH na 15 % se netýká všech

Snížení DPH na 15 % se netýká všech

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Lupa.cz: Insolvenční řízení kvůli cookies? Vítejte v ČR

Insolvenční řízení kvůli cookies? Vítejte v ČR

120na80.cz: Na ucho teplý, nebo studený obklad?

Na ucho teplý, nebo studený obklad?

Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Vitalia.cz: Jmenuje se Janina a žije bez cukru

Jmenuje se Janina a žije bez cukru

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

Podnikatel.cz: Chaos u EET pokračuje. Jsou tu další návrhy

Chaos u EET pokračuje. Jsou tu další návrhy

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu

Vitalia.cz: Znáte „černý detox“? Ani to nezkoušejte

Znáte „černý detox“? Ani to nezkoušejte