.. _protokol-ssh-1: Protokol SSH ------------ 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. |image4| 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) 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: .. table:: Algoritmy domlouvané při vytváření SSH spojení. +------------------------------+-----------------------------------+ | **kex_algorithms** | algoritmy pro domlouvání klíčů | | | (viz 1.2.2) | +------------------------------+-----------------------------------+ | **server_host_key_algo\ | algoritmy soukromého/veřejného | | rithms** | klíče (server může mít více klíčů | | | pro svoji autentizaci) | +------------------------------+-----------------------------------+ | **encryption_algorithms | symetrické šifry pro přenos od | | client_to_server** | klienta k serveru | +------------------------------+-----------------------------------+ | **encryption_algorithms | symetrické šifry pro přenos od | | server_to_client** | serveru ke klientovi | +------------------------------+-----------------------------------+ | **mac_algorithms | algoritmy pro výpočet MAC při | | client_to_server** | přenosu od klienta k serveru | +------------------------------+-----------------------------------+ | **mac_algorithms | algoritmy pro výpočet MAC při | | server_to_client** | přenosu od serveru ke klientovi | +------------------------------+-----------------------------------+ | **compression_algorithms | kompresní algoritmy od klienta | | client_to_server** | k serveru | +------------------------------+-----------------------------------+ | **compression_algorithms | kompresní algoritmy od serveru ke | | server_to_client** | 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. .. table:: Algoritmy podporované v PuTTY a v OpenSSH na serveru bis.vse.cz +-----------------+-----------------------+-----------------------+ | skupina | protokoly podporované | protokoly povolené na | | algoritmů | v klientovi PuTTY | serveru bis.vse.cz | | | verze 0.70 | (OpenSSH 6.7, Debian | | | | 8) | +=================+=======================+=======================+ | domlouvání | | curve25519-sha256 | | curve25519-sha256 | | klíčů | | ecdh-sha2-nistp256 | | ecdh-sha2-nistp256 | | (key exchange, | | ecdh-sha2-nistp38 | | ecdh-sha2-nistp384 | | kex) | | ecdh-sha2-nistp521 | | ecdh-sha2-nistp521 | | | | diffie-hellman-gr\ | | diffie-hellman-gr\ | | | oup-exchange-sha256 | oup-exchange-sha256 | | | | diffie-hellman-gr\ | | | | oup-exchange-sha1 | | | | | diffie-hellman-gr\ | | | | oup-14-sha1 | | | | | diffie-hellman-gr\ | | | | oup-1-sha1 | | | | | rsa2048-sha256 | | | | | rsa1024-sha1 | | +-----------------+-----------------------+-----------------------+ | algoritmy | | ed25519 | | ed25519 | | veřejného klíče | | ecdsa-sha2-nistp256 | | ecdsa-sha2-nistp256 | | pro autentizaci | | ecdsa-sha2-nistp384 | | ecdsa-sha2-nistp384 | | serveru | | ecdsa-sha2-nistp521 | | ecdsa-sha2-nistp521 | | | | rsa | | rsa | | | | dss | | +-----------------+-----------------------+-----------------------+ | symetrická | | chacha20-poly1305 | | chacha20-poly1305 | | šifra | | aes256-ctr | | aes256-gcm | | (encryption) | | aes256-cbc | | aes128-gcm | | | | rijndael-cbc | | aes256-ctr | | | | aes192-ctr | | aes192-ctr | | | | aes192-cbc | | aes128-ctr | | | | aes128-ctr | | | | | aes128-cbc | | | | | blowfish-ctr | | | | | blowfish-cbc | | | | | 3des-ctr | | | | | 3des-cbc | | | | | arcfour256 | | | | | arcfour128 | | +-----------------+-----------------------+-----------------------+ | algoritmy pro | | hmac_sha2-256 | | hmac-sha2-512-etm | | ověření | | hmac_sha1 | | hmac-sha2-256-etm | | integrity | | hmac_sha1_96 | | hmac-ripemd160-etm | | a autenticity | | hmac_md5 | | umac-128-etm | | zpráv (MAC) | | | 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. |image5| 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. 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**). |image6| 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. 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]_. 1. **gssapi** – ověření pomocí Kerberos tiketů. 2. **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.** 3. **publickey** – autentizace pomocí veřejného a soukromého klíče uživatele. Podrobnější popis je dále. 4. **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). 5. **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: 1. Uživatel nejdříve vygeneruje svoji dvojici soukromý/veřejný klíč. Soukromý klíč je obvykle chráněn pomocí hesla. 2. 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). 3. | 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. 4. 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. 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ů: .. table:: 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í. .. |image0| image:: ./media/ssh_image1.png :width: 5.91667in :height: 3.32292in .. |image1| image:: ./media/ssh_image3.png :width: 5.91667in :height: 2.98958in .. |image2| image:: ./media/ssh_image5.png :width: 6.3in :height: 3.27083in .. |image3| image:: ./media/ssh_image7.png :width: 6.1875in :height: 5.01042in .. |image4| image:: ./media/ssh_image9.png :width: 2.94861in :height: 2.15278in .. |image5| image:: ./media/ssh_image11.png :width: 5.65625in :height: 2.75in .. |image6| image:: ./media/ssh_image13.png :width: 4.72778in :height: 3.97153in .. |image7| image:: ./media/ssh_image15.png :width: 4.82292in :height: 5.01042in .. |image8| image:: ./media/ssh_image17.png :width: 6.29861in :height: 2.29861in .. |image9| image:: ./media/ssh_image19.png :width: 4.61389in :height: 3.50694in .. |image10| image:: ./media/ssh_image21.png :width: 6.3in :height: 2.90972in .. |image11| image:: ./media/ssh_image23.png :width: 2.54097in :height: 5.32917in .. |image12| image:: ./media/ssh_image25.png :width: 5.09444in :height: 5.3125in .. |image13| image:: ./media/ssh_image27.png :width: 5.08403in :height: 5.29861in .. |image14| image:: ./media/ssh_image29.png :width: 4.83264in :height: 5.00694in .. |image15| image:: ./media/ssh_image31.png :width: 5.55139in :height: 1.50625in .. |image16| image:: ./media/ssh_image33.png :width: 2.3125in :height: 1.88125in .. |image17| image:: ./media/ssh_image35.png :width: 1.90625in :height: 2.68681in .. |image18| image:: ./media/ssh_image37.png :width: 4.67708in :height: 4.86533in .. |image19| image:: ./media/ssh_image39.png :width: 5.82222in :height: 3.84375in .. |image20| image:: ./media/ssh_image41.png :width: 3.03889in :height: 2.90278in .. |image21| image:: ./media/ssh_image43.png :width: 4.70069in :height: 2.68056in .. |image22| image:: ./media/ssh_image45.png :width: 6.3in :height: 1.86389in .. |image23| image:: ./media/ssh_image47.png :width: 3.03543in :height: 2.97161in .. |image24| image:: ./media/ssh_image49.png :width: 6.3in :height: 2.21528in .. |image25| image:: ./media/ssh_image51.png :width: 6.18889in :height: 2.29167in .. |image26| image:: ./media/ssh_image53.png :width: 4.775in :height: 3.32917in .. |image27| image:: ./media/ssh_image55.png :width: 5.23958in :height: 1.94792in .. |image28| image:: ./media/ssh_image57.png :width: 5.23958in :height: 2.26042in .. |image29| image:: ./media/ssh_image59.png :width: 4.85347in :height: 2.75in .. |image30| image:: ./media/ssh_image61.png :width: 4.68504in :height: 4.5in .. |image31| image:: ./media/ssh_image63.png :width: 4.70069in :height: 4.91667in