Dalo by se říci, že výsledek přesměrování "vzdáleného" portu je přesně symetrický, opačný než u lokálního, až na to, že vytvoření tunelu vyvolává a ssh spojení navazuje pořád lokální počítač. Tedy

• Ssh se připojí na Tam a autentizuje (viz předhozí díly)

• ssh pošle Tamu požadavek, na přčesměrování portu

• Tam otveře port a čeká

• Když nějaký počítač otevře spojení na přesměrovaný port Tamu, Tam to sdělí Tuna

• Tuna oteveře spojení na cílový počítač, tentokrát 10.5.0.1

Přesměrování vzdáleného portu.

Patřičný příkaz je

ssh -R 1110:10.0.0.10:110 -g -n -N jk@Tam

Přesměrování vzdálených portů lze výhodně využít k překonávání různých maškarád (NAT routerů skrývajících síť s neveřejným adresním prostorem), překážejících firewallů a vůbec různých obstrukcí, zabraňujících otevřít z internetu spojení na místní počítač. (Principy maškárád a vniklé problémy popisovat zde nebudu.) Zřejmě stačí účet na "spřáteleném" počítači, provozujícím sshd a připojeném k svobodnému veřejnému internetu. Příkaz

ssh -R 8080:127.0.0.1:80 -g -n -N jk@Tam
spuštěný z počítače za maškarádou, například s adresou 10.1.1.10, zpřístupní širému internetu lokální webserver. Kdokoli z internetu se na něj bude moci dostat, s adresou http://cele.jmeno.Tam:8080/.

Oblíbený příkaz

ssh -R 1022:127.0.0.1:22 -g -n -N jk@Tam
zpřístupní světu lokální ssh - ssh lze skrz ssh tunelovat jako cokoli jiného.

Můžete namítnout, že tahle možnost, jak snadno překonávat firemní bezpečnostní politiku a drahý firewall není obecně prospěšná. Ale jsou naprosto oprávněná použití, například někteří provideři požadují nehorázné příplatky za přidělení veřejné IP adresy.

• Nejnovější verze ssh klienta od ssh.com se umí chovat jako SOCKS4 proxy. Nemožnost dynamického přesměrování byla značným omezením, ale ze strany protokolu jí ve směru od klienta nic nebrání.

• Tzv. předávání spojení autentizačního agenta umožňuje efektivně řetězit ssh spojení. Stručně - řekněme, že mám veřejnou část klíče uloženou jako oprávněný klíč na serverech A a B, soukromou část klíče mám na pracovní stanici C. Připojení C-A,C-B se realizují snadno. Předávání autentizace umožňuje provést snadno i spojení C-A-B, agent na A předá Bčku autentizaci z C.

• Tunelování X session by si zasloužilo samostatný článek, který snad časem také vznikne.

Ssh umožňuje svázat s použitím konkrétního klíče při autentizaci příkaz, který se po autentizaci vykoná. Co se má spustit a s jakým prostředím se uvede v souboru authorized_keys u přílušného klíče. Je tak možné mít specielní klíče, způsobující například restart počítače, spuštění modemového spojení, zavěšení modemového spojení a podobně. Výhodou je, že takto omezený klíč nemůže být zneužit k ničemu jinému. Nevýhodou absolutní závislost na ochraně souboru souboru authorized_keys.

Je to prosté, ssh můžete včlenit do oblíbených unixových shellových konstrukcí. Například vzdálené zálohování a obnova může vypadat takto

dump -0 -a -f - /usr | ssh jk@Tam "gzip > usr.dump.gz"
...
cd /usr
ssh jk@Tam "cat /dump.usr.gz | gunzip" | restore -f - -r

S ssh jsou vzdálené počítače dostupné stejně snadno, jako blízké. Stačí pár znaků a z příkazu, zapsaného na jednom řádku vstupu shellu se část provede na jednom počíači, část na druhém. Snadné, pohodlné, elegantní a slušně bezpečné, ssh je prostě báječné. Čímž obsah, jež by si zaslouží název "Používáme SSH", prozatím končí.

Démon, běžící se superuživatelskými právy, a komunikující po síti, obvykle přináší problémy. Bohužel, platí to i pro sshd a proto se také uplatní obecná rada služby, které nejsou potřeba, vypnout. Na desktpu, ke kterému nikdo vzdáleně nepřistupuje, namá ssh běžet. V případě OpenSSH by se četnost závažných problému dala odhadnout na o trochu víc než jeden za rok, alespoň poslendí dobou. Například loni se "CRC-32 Compensation Attack Detector Vulnerability" (BID 2347) stala jednou z nejčastěji zneužívaných děr. Ssh od SSH se je na tom podobně, třeba chyba "SSH Short Password Login Vulnerability" (BID 3078) působí opravdu trapně (u uživatele s příliš krátkým heslem ssh démon autentizuje prostě kohokoli). Provoz ssh démona tedy vede k nutnosti občas lepit záplaty. Preventivně je vhodné nepoužívané vlastnosti z ssh démona vyloučit už při kompilaci.

Některé díry v klientech jsou naopak zneužitelné útočícím serverem, takže se uplatňuje i obecné doporučení nespouštět pod superuživatelským účtem nic, u čeho to není nezbytně nutné.

V SSH 1

• Z odposlechnuté komunikace lze přímo určit délku hesla

• Šifra RC4 byla v ssh použita špatně. Řešením je RC4 v ssh nepoužívat.

• Díky vadnému způsobu tvorby seesion id za určitých podmínek SSH1 nechrání dostatečně před man-in-the-middle útokem.

• Za určitých podmínek může útočník vložit do ssh spojení vlastní data. (insertion attack)

• Za určitých podmínek použití přesměrování X Win spojení ohrožuje bezpečnost klienta.

Naštěstí zneužití uvedených problémů, vedoucí k závažnějšímu narušení bezpečnosti, není snadné. Protokol SSH 2 byl navžen po letech zkušeností s SSH 1, takže uvedené chyby neobsahuje a žádná podobně závažná zatím nebyla nalezena.

• Problém distribuce klíčů. Server se autentizuje svým veřejným klíčem, který pak většina klientů ukládá v lokální databázi a při dalších spojeních kontroluje. Jednoduchý způsob, jak ověřit identitu serveru a spolehlivě zabránit man in the middle útoku při prvním spojení, neexistuje. Paranoidní správci serverů si proto s sebou mohou nosit veřejný klíč svého serveru a případně jeho fingerprint vytištěný na kartičce.

• Konfigurace ssh, kdy by se mělo najednou uplatnit spojování klíčů s konkrétními příkazy, omezování uživatelů specielními shelly a chroot prostředím, omezování přístupu uživatelů na přenos souborů do jejich domovského adresáře je složitá a snadno se v ní nadělají chyby.

• Asi největší problém - důvěryhodnost ssh klientů, připojování se z nedůvěryhodných počítačů. Není těžké upravit putty tak, aby ukládala uživatelská jména, hesla a jména počítačů "bokem" do nějakého soboru a nainstalovat je na nezabezpečený Win 98 počítač v internetové kavárně nebo počítačové pracovně. Při připojování ze zcela neznámého počítače je vhodné alespoň si stáhnout a spustit "čistého" klienta z internetu. A samozřejmě, nepoužívat hesla. Upravené ssh klietské programy (pro unix) se vyskytují v rootkitech a patří do standardní výbavy hackerů a takyhackerů. Na podcenění bezpečnosti počítače, odkud se administrátor připojoval, doplatilo při úspěšném průniku například české SuSE.

Závěrem pohlednice z USA