Ssh (secure shell) byl původně vytvořeno Tatu Ylönenenem jako program, který měl nahradit nezabezpečené klasické unixové remote- utility rlogin, rsh, rcp. Rychle si získal popularitu, "něco takového" bylo nutně potřeba, ssh měl otevřenou licenci a jeho použití bylo řádově jednodušší, než třeba ssl telnet. Zřejmě díky úspěchu se původně otevřená licenční politika postupně uzavírala, až se z SSH a především kompletně nové verze protokolu SSH2 stal víceméně komerční produkt, vyvíjený firmou SSH Communications. Naštestí se ukázalo, že přejít na uzavřený kód z otevřeného, a "zavřít" jednou osvobozený program do nějaké té krabice, není tak jednoduché - uživatelé si SSH vzít nenechali. V mateřském náručí OpenBSD vzniklo OpenSSH, volně šiřitelné pod licencí typu BSD (stručně řečeno, s kódem je možno činit vcelku cokoli komerčního, nekomerčního, otevřeného i uzavřeného a publikovat jej dále pod jakoukoli licencí). OpenSSH dnes jasně převládá. Protokol SSH má dvě zásadní odlišné verze SSH1 a SSH2. Verze jsou sice nekompatibilní, ale OpenSSH bez problémů zahrnuje obě, takže rozdíl není na první pohled příliš patrný. Popisovat budeme SSH1, protože je jedodušší.

Jak probíhá taková SSH session

• Naváže se tcp spojení (server standardně poslouchá na portu 22)

• Server se představí (např. jmenuji se SSH-1.99-OpenSSH_2.9p2, hovořím SSH2, atp.)

• Klient se představí (např. SSH-2.00-OpenSSH_2.9p2...)
  

• Pokud některá strana zjistí, že by si nerozuměli, spojení ukončí
  

Autentizace serveru

• Server pošle svůj hostkey (trvalý veřejný RSA klíč), povídaní o tom, co všechno umí a koláček (hezky česky)
  

• Server pošle svůj server key (RSA klíč generovaný v pravidelných intervalech, např. jednou za hodinu)
  

• Klient vygeneruje sessionkey, zašifruje je oběma klíči serveru (nejprve kratším)
  

• Klient pošle zašifrovaný sessionkey, pošle povídání o tom, jak se bude šifrovat, a vrátí koláček
  

• V tom okamžiku obě strany začnou šifrovat. (běžně např. idea, DES, 3DES, blowfish)
  

Klient se autentizuje. Ssh podporuje několik metod ověření identity uživatele, například heslem, OTP, trojhlavého psa Kerbera, s pomocí kartiček SecuID. Pro nás asi nejzajímavější možnosti je RSA autentizace. V SSH2 byla nahrazena DSA autentizaci, ale protože z hlediska použití se metody neliší, popíšeme jen RSA. Vygenerují se dva klíče - privátní, který uživatel střeží jako oko v hlavě na bezpečném počítači a veřejný, který naopak může bez obav nahrávat na servery, proti nimz se chce autentizovat.

• Klient nabídne metody autentizace a na RSA se se serverem dohodnou
  

• Klient pošle svůj veřejný klíč
  

• Server už ale správné veřejné klíče má, porovoná je s tím, co zaslal klient a případně pokus zamítne
  

• Server vygeneruje výzvu a zašifruje ji veřejným klíčem klienta
  

• Klient výzvu rozšifruje, pokud to umí :-), a spočítá z ní a nějakých oběma stranám společných informací, založených na koláčku, hash
  

• Hash pošle serveru, ten ji porovná a klienta úspěšně autentizuje
  

Dále - se spustí shell? Kdepak, ssh toho umí víc, takže klient ješte musí formulovat, co po serveru chce - mimo jiné může chtít

• Zapnutí komprese

• Alokování terminálu

• Přesměrování X11

• Přesměrování nějakého portu ze serveru na klienta, případně naopak

• Provedení konkrétního příkazu

• Spuštění shellu a přechod do interaktivního režimu

Pak probíhá spojení, které časem skončí. Popis by sice byl zajímavý (i z bezpečnostího hlediska, bezpečné ukončení styku je velmi důležité!), ale ne až tak zajímavý. Snad jen, že ssh se dokáže vzdorovat i dosti nepříznivému síťovému počasí, je asynchronní a v interaktivním režimu posílá data zajímavým způsobem - co stisk klávesy, to packet. Spojení je vzhledem k šifrování dobře zabezpečeno proti "ukradení" třetí stranou a odposlechu. SSH1 není příliš zabezpečeno proti man-in-the-middle útoku.

• uvedené příklady a jména souborů jsou z OpenSSH na FreeBSD, v jiných implementacích se mohou mírně lišit. V serverech pro Win se mohou zásadně lišit.

V případě RSA autentizace ssh spojení se vzácně pojí bezpečnost s pohodlností. Pokud máme nějaký "bezpečný počítač", například desktop za firewallem, ze kterého vzdáleně přistupujeme k vzdáleným serverům, s jedním RSA klíčem vystačíme pro všechny počítače a hesla můžeme zapomenout. Nebo napsat na papírkym a uložit do trezoru. Na klientu si vygenerujeme pár klíčů něčím jako

ssh-keygen
ssh-keygen -d #pro DSA

Výsledkem jsou dva soubory, běžně identity a identity.pub. Pak stačí jen dostat veřejný klíč, tedy obsah souboru identity.pub, na počítače, kam se chceme přihlašovat. Pokud jsme dosud používali hesla, můžeme k tomu použít přibližně

cat identity.pub |
ssh jk@alnilam.krypta.cz 'cat >> /home/jk/.ssh/authorized_keys'

Při příštím příhlášení už nemusíme zadávat heslo, resp. musíme zadávat heslo k RSA klíči, ale ne k vzdálenému systému.

Důležitá poznámka - zde pozor na verze! V SSH2 se patřičné soubory jmenují například id_dsa, id_dsa.pub a authorized_keys2, a při vyváření klíčů je potřeba ssh-keygen upozornit, aby generoval DSA klíče. Servery jsou většinou nakonfigurované tak, že pokud server i klient umí SSH2, použijí jej. U jednou navázaného spojení ale není žádná možnost návratu k předchozí verzi protokolu, RSA autentizace není v SSH2 podporována a pokud jste si vygenerovali RSA klíče, DSA autentizace se nezdaří a většinou dojde k fallbacku na "password".

Pokud se chceme zbavit i otravnosti s heslem klíče, máme v zásadě dvě možnosti. Používat nezašifrovaný soukromý klíč - někdy je to celkem dobře možné, pokud třeba na dosti zabezpeném počítači pracujeme sami a dostat se k souboru s privátním klíčem je pro útočníka přesně stejně složité, jako pozměnit vlastní ssh. Druhou možností je program ssh-agent, který si rozšifrované verze klíčů umí nacachovat. Spustíme-li například

ssh-agent startx

X session tímto způsobem, a pak kdekoli uvnitř přidáme do cache soukromý klíč,

ssh-add

bude k disposici kterémukoli programu v rámci x-session. Také je možné inforamci o běžícím ssh-agentovi předávat programům nastavením prostředí, blíže viz manulálová stránka.

A to je vše, zadávání hesel je konec. Jen pro inspiraci - vedle ikonky xtermu je možné si na pracovní plochu umístit například ikonky "shell na počítači x", "shell na počítači y", spuštějící v xtermu "ssh x", "ssh y". Jiné ikonky mohou nést jiné specifické příkazy - "ssh x prikaz", poklepáním pak můžeme například vzdálené počítače vypínat, nutit k navazování ppp spojení, spouštět mp3, opékat topinky a podobně. Vše dobře zabezpečeno.

K zadávání příkazů a možnému použití při stavbě potrubí se ještě vrátíme, stejně jako problém, které RSA autentizace přináší, a případně výhodnějšímu použití RSArhost.

Jen menší poznámka - ssh předchází i různým ip- a dns- spoofing útokům. Při prvním připojení k nějakému serveru nás klient upozorní, že hostkey serveru dosud není v databázi důveryhodných strojů a nabídne přidání. Pokud by se při některém dalším přihlášení hostkey servu změnil, ssh klient nás opět buďto hlasitě upozorní, nebo spojení vůbec zruší. Největší hrozbu by komunikace s útočníkovým serverem představovala samozřejmě při autentizaci heslem, s RSA/DSA klíči se můžeme cítit bezpečněji. Za běžného provozu se hostkey nemá důvodu měnit a změna by měla vyvolat maximální obezřetnost.

Na různých unices a unix-like systémech je ssh dnes asi stejně běžné, jako třeba bash. Nevím, zda ještě někde jinde, proto se oddíl nejmenuje na "SSH na neunixových systémech". Celkem jistě není ssh samozřejmé u Microsoftu. Seznam některých zajímavých nebo známých implementací