Koubek Filip, G 262
SSH
Popis problematiky protokolu SSH je velmi podobný popisu protokolu Telnet. SSH (Secure Shell) je protokol sloužící - podobně jako Telnet - k přístupu ke vzdálenému počítači, důležitý rozdíl však spočívá v tom, že veškerá komunikace probíhající pomocí protokolu SSH je šifrovaná, a tedy podstatně bezpečnější než prostřednictvím protokolu Telnet. Bývá často udáváno, že protokol SSh je "bezpečnější náhradou" protokolů jako telnet, ftp, rsh, rcp, rlogin a dalších. Protokol se skládá ze tří hlavních složek: transportní vrstva, ověřování uživatele, spojení.
SSH je uživatelsky podobné protokolu Telnet. Ke komunikaci pomocí protokolu SSH se používají nejrůznější klientské programy. Pomocí klientského programu je následně možné připojit se ke vzdálenému počítači, přihlásit se k němu (nutnou podmínkou je opět uživatelské konto), spouštět příkazy na vzdáleném počítači a přesouvat soubory z jednoho počítače na druhý. SSH poskytuje poměrně silnou autentikaci a bezpečnou komunikaci (a to i po nezabezpečených komunikačních kanálech).
Aby bylo možné začít využívat bezpečnou komunikaci pomocí protokolu SSH, je nutné mít odpovídající klientský program. Standardní součástí systému Windows takový program není, proto je nutné poohlédnou se po externích zdrojích. V následujících odstavcích si podrobněji popíšeme program SecureCRT. Pokud používáte některou UNIXovou distribuci (např. Linux), máte automaticky Secure Shell přítomen, takže není nutné hledat jiné balíky. V případě Linuxu je syntaxe intuitivní a podobná jako v případě protokolu telnet - ssh název_vzdáleného_stroje. Syntaxe je samozřejmě mnohem rozsáhlejší a možnosti širší, nicméně základní ovládání je podobné jako pro program telnet sloužící ke komunikaci pomocí protokolu Telnet.
Každý server musí mít svůj host key. Může jich mít několik, s každým může používat jiné algoritmy. Více serverů může sdílet stejný host key. Každý server musí mít pro každý z vyžadovaných algoritmů pracujících s veřejným klíčem (momentálně pouze DSS) alespoň jeden klíč.
Lze použít dva modely důvěřování si:
Klient si udržuje lokální databázi, v níž je každému jménu serveru přiřazen jeho veřejný klíč. Tato metoda nevyžaduje žádnou centrálně spravovanou databázi, nicméně objem databáze může časem přerůst přijatelnou mez.
Přiřazení "jméno - host key" potvrzuje důvěryhodná autorita. Klient zná pouze klíč této autority a může si ověřit platnost klíčů všech serverů, kterým autorita důvěřuje. Klient si tedy udržuje jediný klíč, nicméně oproti předchozí metodě se zvyšuje zátěž centrální infrastruktury. Protokol umožňuje i spojení bez kontroly přiřazení "jméno - host key", dochází-li ke spojení poprvé. Spojení je chráněno proti pasivnímu naslouchání, nicméně není odolné vůči útokům man-in-the-middle.
Rozšiřitelnost – co se týče zvolených algoritmů, metod a formátů použitých v protokolu, bylo pamatováno na případnou budoucí rozšiřitelnost. Základní protokol je ovšem udržován co nejjednodušší a vyžaduje minimum algoritmů - všechny implementace je však musí podporovat.
Bezpečnostní opatření – server by měl mít zakázáno spouštět příkazy na straně klienta.
Protokol SSH umožňuje použít pro každý směr komunikace jiný algoritmus šifrování, výměny klíčů apod. Je však nutné vždy specifikovat, který algoritmus je preferován. Stejně tak lze určit stupeň ověřování jednotlivých uživatelů.
Všechny používané algoritmy jsou známé a zavedené, využívají klíče takových velikostí, které jsou prakticky neprolomitelné. Kdykoliv je možné snadno přejít na jiný algoritmus, aniž by bylo potřeba změnit základní protokol.
Protokol transportní vrstvy
SSH pracuje nad jakýmkoliv 8-bitovým binary-transparent protokolem bez přenosových chyb. Je mu přiřazen port 22.
Spojení je zahájeno tím, že si obě strany vymění verzi protokolu, kterou používají. Servery s verzí 2.0 mohou posílat kvůli zpětné kompatibilitě s nižšími verzemi protokolu jako číslo verze "1.99". Klient, který používá protokol verze 2.0, musí ovšem být schopen toto identifikovat jako "2.0". Po výměně čísel verzí se obě strany přizpůsobí nižší z nich a vymění si své klíče. Jediná vyžadovaná metoda pro tuto výměnu je Diffie-Hellmanův algoritmus. Výměna by měla proběhnout ve dvou až třech výměnách paketů.
Struktura paketu je následující:
Packet_Length (32 bitů) - délka
paketu v bytes (bez MAC a bez sebe sama)
Padding_Length (8 bitů)
- délka vycpávky v bytes
Payload (Packet_Lenght -
Padding_Length -1) - užitečný obsah paketu
Padding -
minimálně 4 byte; měla by se skládat z náhodných
bytes
MAC - Message Authentication Code
Minimální velikost jednoho paketu je 16 bytes + MAC, maximální velikost 32 768 bytes (včetně Packet_Length, Padding_Length, Payload, Padding a MAC). Některé implementace však mohou podporovat i větší pakety.
Pokud se obě strany dohodly na kompresi, bude užitečný obsah paketu komprimován. Délky a MAC se spočítají podle komprimovaného obsahu. V současné době není žádná metoda komprese definována jako vyžadovaná, lze však případně použít kompresi "zlib" jako volitelnou.
Na algoritmu šifrování a klíči se obě strany dohodnou při výměně klíčů: každá strana pošle seznam podporovaných algoritmů, z nichž jeden je upřednostňován. Přitom se může pokusit hádat, který algoritmus upřednostňuje druhá strana, a nabídnout přímo ten. Možné algoritmy: three-key 3DES (vyžadovaný), BLOWFISH (doporučený), ARCFOUR, IDEA, CAST-128.
Výsledkem výměny je sdílená tajná hodnota K a výměnný hash H, z nichž se odvodí klíče pro šifrování a ověřování. Hodnota H se navíc používá jako identifikátor seance, v jejím průběhu se již nemění, i kdyby došlo ke změně klíčů. Šifrovací klíče se z K počítají pomocí hashovací funkce HASH, která se používala při výměně klíčů:
počáteční hodnota "klient -> server": HASH(K || "A" || session_id)
počáteční hodnota "server -> klient": HASH(K || "B" || session_id)
šifrovací klíč "klient -> server": HASH(K || "C" || session_id)
šifrovací klíč "server -> klient": HASH(K || "D" || session_id) atd.,
kde A, B, C, D jsou jednoduché znaky (ASCII 65-68). Pokud je výstup funkce HASH kratší než klíč, rozšíří se klíč výpočtem HASH z konkatenace K a dosud získaného klíče. Tento postup se opakuje, dokud není klíč dostatečně dlouhý. Jinými slovy (X je například "A"):
K1 = HASH(K || X || session_id)
K2
= HASH(K || K1)
K3 = HASH(K || K2)
...
key = K1 || K2 ||
K3 || ...
Protokol ověřování uživatele
Jedinou vyžadovanou metodou ověřování uživatele je metoda veřejného klíče. Všechny implementace musí tuto metodu podporovat. Jako ověření při ní slouží vlastnictví soukromého klíče. Z něj se vytvoří podpis. Server zjišťuje, zda je je klíč platný pro daného uživatele a zda je platný i podpis. Pokud některá z položek platná není, ověření končí neúspěšně.
Soukromý klíč je v zakódované podobě uložen na klientském počítači, uživatel musí zadat tzv. passphrase, aby bylo možné vygenerovat podpis. Ten se skládá z identifikátoru seance a položky Payload paketu bez podpisu.
Heslo se kóduje na úrovni transportní vrstvy, je tedy nutné, aby si obě strany ověřily, že tato vrstva zaručuje bezpečnost (t.j. že se na ní využívá šifrování).
Host-based ověřování – tento systém je podporován i v SSH (jde o obdobu UNIXového "rhosts"), nicméně pouze jako volitelná varianta - není vhodný pro servery vyžadující velkou míru bezpečnosti.
Klient při host-based ověřování posílá podpis vytvořený soukromým klíčem svého počítače, jenž server ověří proti veřejnému klíči daného počítače. Jakmile se provede toto ověření, funguje autorizace na základě uživatelských jmen na serveru i klientském počítači. Podpis se vytváří stejně jako v předchozím odstavci. Server po jeho přijetí ověřuje, zda klíč skutečně patří počítači uvedenému ve zprávě, zda má na něm daný uživatel právo logovat se a zda je podpis platný, odpovídající hodnotě daného klíče. Server může ignorovat uživatelské jméno, chce-li ověřit pouze klientský počítač.
Spojení – Mechanismus kanálů
Všechny terminálové seance, forwardovaná spojení apod. jsou kanály. Každá ze stran může otevřít kanál. Více kanálů je multiplexováno do jednoho spojení.
Kanály se identifikují číslem na každém konci. Čísla odpovídající oběma koncům jednoho kanálu mohou být různá. Požadavek na vytvoření kanálu obsahuje číslo tohoto kanálu u odesílatele. Všechny ostatní zprávy týkající se kanálů obsahují číslo kanálu na straně příjemce.
Otevření kanálu – pokud chce některá ze stran otevřít nový kanál, alokuje pro něj číslo. Druhé straně pošle toto číslo spolu s navrhovanou velikostí okna (t.j. kolik bytes dat kanálu možno příjemci poslat, aniž by bylo nutné měnit velikost okna) a maximální velikostí paketu. Některé kanály mohou přenášet různé typy dat, což je také nutno specifikovat.
Uzavření kanálu – pokud chce kterákoliv ze stran kanál uzavřít, pošle o tom zprávu druhé straně. Na tuto zprávu musí příjemce odpovědět, pokud již sám zprávu o uzavření kanálu neposlal. Po odeslání a přijmutí zprávy o uzavření (bez ohledu na pořadí těchto zpráv) daná strana kanál považuje za uzavřený, jeho číslo může znovu použít.
Interaktivní seance je vzdálené spuštění programu. Programem může být shell, aplikace, systémový příkaz nebo nějaký zabudovaný subsystém. Může, ale nemusí mít tty, může, ale nemusí zahrnovat forwardování X11. Více seancí může být aktivních současně.
Klient otevře kanál a požádá o pseudoterminál. Musí serveru poslat údaje o obsahu proměnné TERM, o šířce a výšce okna ve znacích a v pixelech.
Forwardování X11
Klient posílá zprávu se žádostí o forwarding, v níž uvádí mimo jiné číslo kanálu, ověřovací protokol, ověřovací cookie a číslo obrazovky. Při uzavření kanálu forwardovaní X11 skončí, všechny otevřené forwardy se zruší.
Žádá-li klient o otevření kanálu pro forwardování X11, musí navíc udat i svou IP adresu a číslo portu.