2.3. Protokol SSH¶

2.3.1. Architektura protokolu SSH¶

SSH používá klient-server architekturu – uživatel se připojuje prostřednictvím klienta obvykle ze svého osobního počítače na server. Server je proces, který poslouchá obvykle na TCP portu 22. Uživatel musí v klientovi zadat adresu serveru (IP adresu či doménové jméno) a volitelně číslo portu.

Protokol SSH se skládá ze tří základních protokolů, nad kterými mohou být další aplikace.

transportní protokol/vrstva (SSH Transport Layer Protocol)

autentizace uživatele (SSH Authentication Protocol)

protokol spojení (SSH Connection protocol)

2.3.2. Transportní vrstva – vytvoření spojení¶

Cílem transportního protokolu je vytvořit zašifrované (důvěrné) spojení se zajištěním integrity a autenticity zpráv. Při vytváření SSH spojení se domlouvají používané algoritmy a klíče sezení, ověřuje se autenticita serveru. Poté se vytvoří transportní vrstva, která přenáší zprávy z vyšších vrstev.

Při vytváření spojení se domlouvají následující algoritmy:

Tabulka 2.2 Algoritmy domlouvané při vytváření SSH spojení.¶
kex_algorithms	algoritmy pro domlouvání klíčů (viz 1.2.2)
server_host_key_algorithms	algoritmy soukromého/veřejného klíče (server může mít více klíčů pro svoji autentizaci)
encryption_algorithms client_to_server	symetrické šifry pro přenos od klienta k serveru
encryption_algorithms server_to_client	symetrické šifry pro přenos od serveru ke klientovi
mac_algorithms client_to_server	algoritmy pro výpočet MAC při přenosu od klienta k serveru
mac_algorithms server_to_client	algoritmy pro výpočet MAC při přenosu od serveru ke klientovi
compression_algorithms client_to_server	kompresní algoritmy od klienta k serveru
compression_algorithms server_to_client	kompresní algoritmy od serveru ke klientovi

Z tabulky je zřejmé, že v každém směru přenosu může být použito jiné šifrování. Doporučuje se používat stejné algoritmy v obou směrech.

Podporované algoritmy se mohou lišit v jednotlivých verzích programů. Navíc uživatel (správce serveru) může omezit algoritmy v konkrétní instalaci. Občas se stane, že se starý klient nepřipojí na nový server. V následující tabulce jsou uvedeny algoritmy, které podporuje program PuTTY v aktuální verzi, a algoritmy, které nabízí pro spojení server bis.vse.cz. Algoritmy jsou seřazeny dle preference.

Tabulka 2.3 Algoritmy podporované v PuTTY a v OpenSSH na serveru bis.vse.cz¶
skupina algoritmů	protokoly podporované v klientovi PuTTY verze 0.70	protokoly povolené na serveru bis.vse.cz (OpenSSH 6.7, Debian 8)
domlouvání klíčů (key exchange, kex)	curve25519-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp38 ecdh-sha2-nistp521 diffie-hellman-group-exchange-sha256 diffie-hellman-group-exchange-sha1 diffie-hellman-group-14-sha1 diffie-hellman-group-1-sha1 rsa2048-sha256 rsa1024-sha1	curve25519-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group-exchange-sha256
algoritmy veřejného klíče pro autentizaci serveru	ed25519 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 rsa dss	ed25519 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 rsa
symetrická šifra (encryption)	chacha20-poly1305 aes256-ctr aes256-cbc rijndael-cbc aes192-ctr aes192-cbc aes128-ctr aes128-cbc blowfish-ctr blowfish-cbc 3des-ctr 3des-cbc arcfour256 arcfour128	chacha20-poly1305 aes256-gcm aes128-gcm aes256-ctr aes192-ctr aes128-ctr
algoritmy pro ověření integrity a autenticity zpráv (MAC)	hmac_sha2-256 hmac_sha1 hmac_sha1_96 hmac_md5	hmac-sha2-512-etm hmac-sha2-256-etm hmac-ripemd160-etm umac-128-etm hmac-sha2-512 hmac-sha2-256 hmac-ripemd160 umac-128

Při vytváření SSH spojení se ověřuje autenticita serveru – ověřuje se jeho veřejný klíč, a že k němu má server soukromý klíč. Postup je popsán v předchozí kapitole, kterou jsme ukončili konstatováním slabiny – útočník může podvrhnout svoje klíče pomocí útoku Man-in-the-Middle.

SSH částečně spoléhá na uživatelovo ověření klíče serveru. Při prvním připojení na konkrétní server se uživateli zobrazí otisk veřejného klíče serveru (fingerprint) a uživatel by ho měl ověřit u správce serveru. Je na klientovi, zda bude se serverem dále komunikovat. Pokud uživatel potvrdí, že se jedná o důvěřuje zobrazenému otisku, tak si klient uloží jméno a klíč serveru do souboru (v Unixu soubor ~/.ssh/known_hosts) či ve Windows do registrů. Při druhém a dalším připojení ke stejnému serveru se kontroluje, zda vrací stejný klíč, který má již klient pro jméno serveru uložen.

Při odlišném klíči unixový klient spojení obvykle odmítne. Pokud chce uživatel používat nový klíč (např. po přegenerování klíče na serveru), tak musí nejdříve smazat starý klíč v ~/.ssh/known_hosts .

Program putty.exe zobrazí upozornění a nechá na rozhodnutí uživatele, zda akceptuje nový klíč.

Veřejný klíč SSH serveru může být uložen v DNS 15 – klienti poté ověří klíč vůči tomuto záznamu a uživatele se neptají. PuTTY či WinSCP ověření vůči DNS nepodporují. RFC 6187 popisuje ověření pomocí certifikátů – tato možnost je v implementacích protokolu málo rozšířena.

2.3.3. Transportní vrstva – vlastní přenos¶

Po dohodnutí algoritmů, klíčů a po autentizaci serveru se všechny přenášené údaje šifrují pomocí symetrické šifry a zabezpečnují pomocí kódu pro ověření zprávy (MAC, Message Authentication Code).

Pro každý směr přenosu (od klienta k serveru a od serveru ke klientovi) se nezávisle počítají odeslané zprávy – je to ochrana proti útoku opakováním. Pořadové číslo zprávy se na druhou stranu nepřenáší.

Zpráva (používá se pojem payload – užitečný náklad) se nejdříve volitelně zkompresuje a poté se k ní připojí náhodná vycpávka (padding) o minimální délce 4B.

Následně se počítá MAC – do něho se zahrne i pořadové číslo odesílané zprávy. Následně se data zašifrují.

Na druhou stranu se pošlou zašifrovaná data a MAC. Příjemce dešifruje data a následně spočítá vlastní MAC.

Po větším množství přenesených dat či po určité době se obě strany mohou domluvit na nových klíčích.

Po vytvoření bezpečného spojení následuje autentizace uživatele.

2.3.4. Autentizace uživatele¶

Po navázání šifrované komunikace a vytvoření bezpečného spojení začne autentizace uživatele. Nejdříve server pošle klientovi podporované typy autentizace. Klient se poté postupně zkouší autentizovat pomocí uvedených typů (nemusí použít všechny možnosti). Následují standardizované typy autentizace v obvyklém pořadí ověřování 16.

gssapi – ověření pomocí Kerberos tiketů.
hostbased – server důvěřuje autentizaci uživatele na počítači, ze kterého se hlásí. Například u uživatele bob na serveru B může být napsáno, že pokud se bude hlásit uživatelka alice ze serveru A, tak se nemá vyžadovat heslo. Principiálně nebezpečné, neboť nelze zajistit, aby se uživatel malory při přihlašování ze serveru A nevydával za uživatel alice. Obvykle zakázáno.
publickey – autentizace pomocí veřejného a soukromého klíče uživatele. Podrobnější popis je dále.
keyboard-interactive (challenge-response) – server postupně posílá dotazy klientovi a uživatel na ně odpovídá, dokud server nakonec nerozhodne, zda se uživatel autentizoval či ne. Používá se např. u jednorázových hesel či při vícefaktorové autentizaci. Lze použít i pro přihlašování pomocí běžných hesel (nedoporučuje se).
password – autentizace pomocí hesla. Klient zjistí od uživatele heslo a poté ho nezašifrované pošle ve vytvořeném bezpečném spojení na server, kde se ověří.

Autentizace uživatele pomocí soukromého/veřejného klíče je v principu podobné autentizaci serveru:

Uživatel nejdříve vygeneruje svoji dvojici soukromý/veřejný klíč. Soukromý klíč je obvykle chráněn pomocí hesla.
Uživatel svůj veřejný klíč umístí na server. Způsob není určen – může sám po přihlášení pomocí hesla či prostřednictvím správce či webové aplikace, ke které se přihlásí (to používá např. github).
Klient vytvoří autentizační zprávu (obsahuje uživatelské jméno, veřejný klíč a několik dalších údajů) a tu digitálně podepíše pomocí uživatelova soukromého klíče 17.

Na uživatelské jméno se klient zeptá uživatele, zjistí ho z konfiguračního souboru či použije jméno, pod kterým je uživatel přihlášen na počítači.
Server vezme odpovídající uložený veřejný klíč uživatele a ověří obdržený digitální podpis. Pokud je v pořádku, tak se uživatel správně autentizoval. Pokud ne, tak vyzve klienta k dalšímu pokusu o autentizaci – např. pomocí jiné dvojice klíčů či pomocí hesla.

Proti autentizaci serveru zde není potřeba posílat ze serveru náhodná data (nonce) – je již vytvořen bezpečný kanál a nehrozí útok opakováním.

Veřejný klíč může být ve formě certifikátu – podepsaný osobní certifikační autoritou uživatele. Uživatel poté na server neumístí všechny své veřejné klíče, ale klíč své certifikační autority. Podpora certifikátů není v implementacích příliš rozšířená.

Na cvičeních budeme používat autentizaci pomocí hesla a pomocí klíče.

2.3.5. Protokol spojení – kanály, základní aplikace¶

Protokol SSH umožňuje zabezpečit téměř jakoukoliv obousměrnou komunikaci mezi dvěma body v síti. Lze například bezpečně kopírovat soubory (scp a sftp), synchronizovat adresáře (rsync+ssh), tunelovat celou komunikaci po vybraný port, nebo zabezpečit nešifrovaný protokol jako je přístup k MySQL databázi nebo X-Window protokol. SSH se často používá v systémech na správu verzí jako je Git či Subversion.

Tuto variabilitu umožňují nezávislé kanály, které se vytvářejí po autentizaci uživatele. Kanálů může být více, kanál může vytvořit libovolná strana komunikace, kanály lze v průběhu spojení přidávat a odebírat. Při ukončení všech kanálů končí i SSH spojení.

Rozlišují se tyto typy kanálů:

Tabulka 2.4 Typy kanálů v SSH.¶
Typ kanálu	Užití kanálu
session	Interaktivní kanál se spuštěním programu na vzdálené straně. Může se použít pro spuštění programu na serveru a zobrazení výsledků. Tento kanál používá i pro přenos souborů – na serveru se spustí modul sftp a lokální klient si s ním vyměňuje soubory a informace ze souborového systému (výpis adresáře, …). Nejčastěji se používá pro emulaci terminálu a spuštění shellu na vzdáleném počítači. Uživatel poté na serveru spouští programy s textovým uživatelským rozhraním.
x11	Kanálu pro grafické aplikace spouštěné na serveru. Grafické okno se zobrazí na počítači klienta, uživatel může používat klávesnici, myš, …
forwarded-tcpip	Tunel, který přesměruje TCP provoz z portu na serveru na klienta (vzdálený tunel).
direct-tcpip	Tunel, který přesměruje TCP provoz z portu klienta na server (lokální a dynamický tunel).

15: Předpokladem je, že DNS záznamy budou zabezpečeny pomocí DNSSEC.
16: V RFC 4252 je ještě definována metoda none bez jakéhokoliv ověření. Nedoporučuje se používat.
17: Klient může zvolit i delší výměnu – nejdříve se serveru zeptá, zda může použít konkrétní veřejný klíče. Pokud server odpoví ano, tak teprve poté odešle podepsanou zprávu. Tato delší cesta ušetří na straně klienta čas procesoru nutný pro vytvoření digitálního podpisu v případě odmítnutého klíče. Též umožňuje, aby se klient ptal na heslo k soukromému klíči pouze v případě, kdy odpovídající veřejný klíč server schválí.