Secure Shell

SSH (Secure Shell) je v informatice označení pro program a zároveň pro zabezpečený komunikační protokol v počítačových sítích, které používají TCP/IP. SSH byl navržen jako náhrada za telnet a další nezabezpečené vzdálené shelly (rlogin, rsh apod.), které posílají heslo v nezabezpečené formě a umožňují tak jeho odposlechnutí při přenosu pomocí počítačové sítě.[1] Šifrování přenášených dat, které SSH poskytuje, slouží k zabezpečení dat při přenosu přes nedůvěryhodnou síť, jako je například Internet.

Charakteristika

SSH umožňuje bezpečnou komunikaci mezi dvěma počítači, která se využívá pro zprostředkování přístupu k příkazovému řádku, kopírování souborů a též jakýkoliv obecný přenos dat (s využitím síťového tunelování). Zabezpečuje autentizaci obou účastníků komunikace, transparentní šifrování přenášených dat, zajištění jejich integrity a volitelnou bezeztrátovou kompresi. Server standardně naslouchá na portu TCP/22.[2]

Označení „Secure Shell“ je mírně zavádějící, protože nejde ve skutečnosti o náhradu shellu ve smyslu interpret příkazů. Název byl odvozen z existujícího programu rsh, který má podobné funkce, ale není zabezpečený.

Historie

Po útoku odchytáváním hesel na počítačovou síť helsinské Technické univerzity (Helsinki University of Technology, Finsko) navrhl Tatu Ylönen první verzi protokolu (SSH-1). V červnu 1995 jej pak uveřejnil včetně zdrojových kódů jako freeware. Do konce roku 1995 se rozrostla základna uživatelů na 20 000 v padesáti zemích.

V prosinci 1995 Ylönen založil společnost SSH Communications Security a začal vyvíjet SSH a další bezpečnostní nástroje. Původní verze SSH používala části svobodného software (např. GNU libgmp), avšak pozdější verze se od těchto závislostí oprostily a změnily se v proprietární software, který byl vydáván pod uzavřenou licencí.

V roce 1996 byla vyvinuta vylepšená verze protokolu SSH-2, která je nekompatibilní s SSH-1. Novinkami v druhé verzi byla zvýšená bezpečnost, která byla zajištěna např. výměnou klíčů pomocí Diffie-Hellman algoritmu (anglicky Diffie-Hellman key exchange) nebo přísnou kontrolou integrity dat pomocí MAC funkce. Novou vlastností SSH-2 je také možnost řídit libovolný počet shellů pomocí jednoho SSH spojení.[3]

Vývojáři, kteří chtěli používat volně šiřitelnou verzi SSH, se v roce 1999 vrátili ke starší verzi 1.2.12 původního SSH, která byla jako poslední vydána jako open source software. Na tomto základě byl dále vyvíjen OSSH Björna Grönvalla. Krátce na to vývojáři OpenBSD vytvořili fork kódu OSSH, udělali v něm rozsáhlé změny a vytvořili tak OpenSSH, které bylo vydáno v OpenBSD verze 2.6. Od této verze byl vytvořen branch OpenSSH, který umožňoval portování i na jiné operační systémy.

Ke konci roku 2000 využívaly SSH přibližně 2 milióny uživatelů.[4]

V roce 2005 se OpenSSH stalo jednou z nejpopulárnějších SSH implementací na mnoha operačních systémech. OSSH se zároveň stalo zastaralým.[5]

V roce 2006 byl protokol SSH-2 navržen jako Internetový standard, který publikovala pracovní skupina IETF „secsh“ jako RFC 4252.[6]

Použití

SSH je používáno jako bezpečná náhrada starších protokolů a nabízí i nové vlastnosti:

  • náhrada protokolu Telnet, práce na vzdáleném počítači přes nezabezpečenou síť
  • náhrada protokolu Rlogin, přihlášení na vzdálený počítač
  • náhrada protokolu Rsh, spouštění příkazů na vzdáleném počítači
  • náhrada protokolů FTP a rcp bezpečným přenosem souborů pomocí SFTP nebo SCP
  • transportní protokol pro programy rsync, git, apod.
  • přihlašování bez hesla pomocí veřejných klíčů
  • komunikace prostřednictvím proxy serverů
  • připojování vzdálených systémů souborů pomocí SSHFS
  • tunelování spojení
  • přesměrování TCP portů a X11 spojení zabezpečeným kanálem
  • automatické vzdálené monitorování a management serverů
  • bezpečné připojování složek na vzdáleném serveru jako souborový systém na lokálním počítači použitím SSHFS
  • prohlížení webu přes šifrované proxy spojení s SSH klientem, který podporuje SOCKS protokol
  • plnohodnotnou šifrovanou VPN (pouze OpenSSH server a klient, kteří tuto vlastnost podporují)

Architektura

Protokol SSH-2 má dobře navrženou vnitřní architekturu (RFC 4251) rozdělenou na oddělené vrstvy. Otevřená architektura nabízí významnou flexibilitu umožňující použití SSH nejen pro zabezpečený shell. Funkce transportní vrstvy samotné je srovnatelná s TLS (Transport Layer Security). Vrstva autentizace uživatele je navržena pro snadné rozšíření vlastními autentizačními metodami. Vrstva spojení nabízí použití více podružných relací přenášených jedním SSH spojením, které je srovnatelné s BEEP (Block Extensible Exchange Protocol) a kteroužto vlastnost TLS nenabízí.

Transportní vrstva

Transportní vrstva (RFC 4253) zajišťuje počáteční výměnu klíčů, serverovou autentizaci, kompresi a ověření integrity. Poskytuje vyšší vrstvě prostředí pro posílání a přijímání nešifrovaných až 32,768 bytů dlouhých paketů dat (prostý text, delší mohou být povoleny implementací). Transportní vrstva také zajišťuje opětovnou výměnu klíčů – obvykle po 1 GB přenesených dat nebo po uplynutí 1 hodiny, podle toho, co nastane dříve.

Vrstva autentizace uživatele

Vrstva autentizace uživatele (RFC 4252) zajišťuje autentizaci klientů, která může být provedena mnoha způsoby. Samotná autentizace je řízena SSH klientem, server pouze reaguje na autorizační požadavky od SSH klienta. Do nejpoužívanějších metod autentizace patří metody:

password
password je metoda pro přímou autentizaci pomocí hesla, zahrnující možnost změny hesla. Tato metoda není implementována ve všech programech.
publickey
publickey je metoda přihlášení pomocí veřejného klíče, obvykle podporuje alespoň DSA nebo RSA klíče, může podporovat i jiné metody založené na X.509 certifikátech. Tato metoda může zabránit útokům hrubou silou (anglicky brute force), ale pouze tehdy, když je vypnuta metoda "password".
keyboard-interactive
keyboard-interactive je univerzální metoda (RFC 4256), při které server pošle klientovi jednu nebo více výzev, na které uživatel odpovídá pomocí klávesnice. Nejčastěji se používá pro jednorázovou autentizaci jako je S/Key nebo SecurID.
GSSAPI
GSSAPI metody poskytují rozšiřitelné rozhraní pro autentizaci pomocí externích mechanizmů jako je Kerberos 5 nebo NTLM, poskytujících možnost centrální autentizace (anglicky Single Sign-On, SSO) pro přihlášení pomocí SSH relace. Tyto metody jsou obvykle používány v komerčních SSH implementacích, určených pro organizace, i když OpenSSH funkční GSSAPI také obsahuje.

Vrstva spojení

Vrstva spojení (RFC 4254) definuje koncept kanálů, požadavků kanálů a globálních požadavků skrze které jsou poskytovány SSH služby. Jedno SSH spojení může hostovat více kanálů zároveň, kdy každý může přenášet data v obou směrech. Požadavky kanálů jsou použity pro přenos mimopásmových dat, jako jsou např. změna velikosti terminálového okna nebo návratový kód procesu na straně serveru. SSH klient si může pomocí globálního požadavku vyžádat forwardování (tunelování) portu na straně serveru. Standardní typy kanálů zahrnují:

shell
shell pro terminálové shelly, SFTP a požadavky exec (zahrnující SCP přenosy)
direct-tcpip
direct-tcpip pro forwardovaná klient-server spojení
forwarded-tcpip
forwarded-tcpip pro forwardovaná server-klient spojení

SSHFP záznamy v DNS

SSHFP záznamy v DNS (RFC 4255) poskytují veřejné otisky klíčů, které usnadňují ověření autenticity hosta (tj. protistrany).

Bezpečnostní výstrahy

Protokol SSH-1 byl označen za zastaralý kvůli bezpečnostním nedostatkům (např. možnost útoku man-in-the-middle), a proto by jeho použití mělo být explicitně znemožněno. Současná situace je taková, že většina moderních serverů a klientů používá SSH-2, ale stále existují některé organizace, které používají software bez podpory SSH-2 a tudíž není možné podporu SSH-1 úplně odstranit.

U všech verzí protokolu SSH je velmi důležité, aby neznámý veřejný klíč byl před jeho schválením řádně ověřen, jinak může dojít k dešifrování důvěrných informací a útokům typu man-in-the-middle.

V srpnu 2018 bylo upozorněno na špatné hashování privátních klíčů, takže lze jejich ochranu heslovou frází snadno prolomit. Doporučuje se klíč uložit v bezpečnějším formátu.[7]

Stejně jako každý šifrovaný protokol, může být SSH považováno za bezpečnostní riziko pro firmy nebo vlády, které nevěří svým zaměstnancům a chtějí mít jejich komunikaci pod kontrolou. Navíc má SSH v sobě zabudované jednoduché mechanismy pro vytváření tunelovaných spojení, skrze které lze přenášet velké objemy dat a vytvářet tak nežádoucí vstupní body, které mohou sloužit k úniku důležitých informací nebo k průniku do vnitřní sítě. Stejně tak mohou být tytéž vlastnosti užitečné (např. šifrování služeb jako je POP3 nebo IMAP prostým použitím SSH tunelu), protože je u jiných protokolů nenajdeme.

Vzhledem k mnoha vlastnostem, které protokol SSH nabízí, se povolení průchodu SSH přes firewall může stát vážným bezpečnostním rizikem. Kromě přesměrováním portů totiž některé implementace SSH přímo podporují Layer2 VPN, což umožňuje efektivní spojení dvou vzdálených ethernetových sítí, jako by byly připojeny ke stejnému switchi. V současnosti se hledá řešení těchto problémů.

Autentizace pomocí veřejného klíče

Pro autentizaci uživatele je možné v SSH použít veřejný klíč. Nejprve je vygenerován pár šifrovacích klíčů – privátní (soukromý) klíč a veřejný klíč. Privátní je bezpečně uložen u uživatele a je chráněn heslovou frází. Veřejný klíč je uložen na cílový server (typicky do domácího adresáře uživatele, v unixových systémech do souboru ~/.ssh/authorized_keys). Při pokusu o přihlášení server veřejným klíčem, který má k dispozici, zašifruje blok náhodných dat (tzv. výzvu typu challenge-response), kterou nelze snadno odvodit nebo uhádnout a pošle ji klientovi. Klient výzvu pomocí privátního klíče dešifruje a dešifrovanou ji pošle zpět serveru. Pokud je výzva správně rozšifrována, má tím server ověřeno, že klient má k dispozici privátní klíč, který odpovídá veřejnému klíči, který má server dispozici, a tudíž může přístup schválit (autorizovat). Pokud výzva nebude správně rozšifrována, bude přístup pro klienta zamítnut. Z toho plyne, že privátní klíč neopustí klientův počítač, tudíž se nemůže stát, že by ho někdo odcizil při přenosu po síti, a přesto může dojít k ověření autenticity klienta a umožnění přístupu.

Související informace naleznete také v článku Asymetrická kryptografie.

Shrnutí

SSH program je dnes běžně používán při vzdálené práci a pro vzdálenou správu. Klient se při navázání spojení připojuje k SSH démonu (SSH daemon, sshd). SSH démon podle svého nastavení rozhoduje, zda spojení přijme, jakou formu autentizace bude požadovat, případně na kterém portu bude naslouchat. Implementace SSH klientů i serverů (SSH démon) je dostupná téměř pro jakoukoliv platformu. Většinou jsou dostupné jak komerční, tak i Open Source varianty.

O oblíbenosti svědčí i to, že koncem roku 2000 používalo SSH 2 000 000 uživatelů.

Seznam implementací

  • Lsh, implementace SSH klientu i serveru spravované v projektu GNU
  • OpenSSH, open source implementace SSH. Původně odštěpená z originálního SSH-1 (klient i server)
  • PuTTY, SSH klient pro Windows
  • SSH Tectia Client [1]
  • PenguiNet [2]
  • SSHDOS [3]
  • WinSCP [4] souborový manažer založený na knihovnách Putty, umožňující práci v režimu sftp a scp
  • JavaSSH [5]
  • Dropbear, malý klient a server určený pro OS splňující normu POSIX
  • Idokorro Mobile SSH [6] implementace SSH pro RIM BlackBerry a mobilní telefony
  • Ganymed-SSH2 Open Source klientská knihovna funkcí SSH2 v jazyku Java
  • SSH přes HTTP
  • TinySSH, minimalistický server pro Linux, *BSD

Reference

  1. SSH Hardens the Secure Shell. www.serverwatch.com [online]. [cit. 2009-01-29]. Dostupné v archivu pořízeném z originálu. 
  2. port-numbers assignments at iana.org
  3. SSH Frequently Asked Questions
  4. Nicholas Rosasco and David Larochelle. How and Why More Secure Technologies Succeed in Legacy Markets: Lessons from the Success of SSH [online]. Dept. of Computer Science, Univ. of Virginia [cit. 2006-05-19]. (Quoting Barrett and Silverman, SSH, the Secure Shell: The Definitive Guide, O'Reilly & Associates (2001)). Dostupné v archivu pořízeném dne 2006-06-25. 
  5. OSSH Information for VU#419241. www.kb.cert.org [online]. [cit. 2009-01-29]. Dostupné v archivu pořízeném dne 2007-09-27. 
  6. RFC 4252
  7. CALETKA, Ondřej. Hesla SSH klíčů jsou špatně hashovaná, lze je prolomit velmi rychle. Root.cz [online]. 2018-08-06 [cit. 2018-09-06]. Dostupné online. 

Externí odkazy