Secure Shell - Secure Shell

„SSH“ přeadresuje tady. Pro jiná použití, viz SSH (disambiguation) .
Secure Shell
Komunikační protokol
Účel zabezpečené připojení, vzdálené CLI
Vývojáři Tatu Ylönen, pracovní skupina pro internetové inženýrství (IETF)
Představeno 1995
OSI vrstva Aplikační vrstva
Port (y) 22
RFC RFC 4250, RFC 4251, RFC 4252, RFC 4253, RFC 4254
Sada internetových protokolů
Aplikační vrstva
Transportní vrstva
Internetová vrstva
Odkazová vrstva

Secure Shell ( SSH ) je kryptografický síťový protokol pro bezpečný provoz síťových služeb přes nezabezpečenou síť. Mezi typické aplikace patří vzdálený příkazový řádek , přihlášení a vzdálené spouštění příkazů, ale jakoukoli síťovou službu lze zabezpečit pomocí SSH.

SSH poskytuje zabezpečený kanál přes nezabezpečenou síť pomocí architektury klient -server a spojuje klientskou aplikaci SSH se serverem SSH . Specifikace protokolu rozlišuje dvě hlavní verze, označované jako SSH-1 a SSH-2. Standardní port TCP pro SSH je 22. SSH se obecně používá pro přístup k operačním systémům podobným unixu , ale lze jej použít také v systému Microsoft Windows . Windows 10 používá jako výchozího klienta SSH a server SSH OpenSSH .

SSH byl navržen jako náhrada za Telnet a za nezabezpečené protokoly vzdáleného shellu , jako je Berkeley rsh a související protokoly rlogin a rexec . Tyto protokoly odesílají citlivé informace, zejména hesla , ve formátu prostého textu , což je činí náchylnými k zachycení a zveřejnění pomocí analýzy paketů . Šifrování používají SSH je určen pro utajení a integritu dat přes nezabezpečenou síť, jako je internet .

Definice

SSH používá kryptografii veřejného klíče k autentizaci vzdáleného počítače a v případě potřeby mu umožňuje autentizaci uživatele.

Existuje několik způsobů, jak používat SSH; Jedním z nich je použít automaticky generované páry veřejného a soukromého klíče k jednoduchému šifrování síťového připojení a poté se přihlásit pomocí ověřování heslem . Další možností je použít ručně generovaný pár veřejného a soukromého klíče k provedení autentizace, což umožní uživatelům nebo programům přihlásit se bez nutnosti zadávat heslo. V tomto scénáři může kdokoli vytvořit odpovídající pár různých klíčů (veřejných a soukromých). Veřejný klíč je umístěn na všech počítačích, které musí umožňovat přístup majiteli odpovídajícího soukromého klíče (vlastník tajný soukromý klíč uchovává). Zatímco ověřování je založeno na soukromém klíči, samotný klíč se během ověřování nikdy nepřenáší přes síť. SSH pouze ověřuje, zda stejná osoba nabízející veřejný klíč vlastní i odpovídající soukromý klíč. Ve všech verzích SSH je důležité ověřit neznámé veřejné klíče , tj. Spojit veřejné klíče s identitami , než je přijmete jako platné. Přijetí veřejného klíče útočníka bez ověření autorizuje neautorizovaného útočníka jako platného uživatele.

Ověření: Správa klíčů OpenSSH

V systémech podobných Unixu je seznam autorizovaných veřejných klíčů obvykle uložen v domovském adresáři uživatele, kterému je povoleno vzdálené přihlášení, v souboru ~/.ssh/authorized_keys. Tento soubor je respektován SSH pouze v případě, že není zapisovatelný ničím jiným než vlastníkem a rootem. Je -li veřejný klíč přítomen na vzdáleném konci a odpovídající soukromý klíč je přítomen na místním konci, není již zadávání hesla vyžadováno. Pro další zabezpečení však lze soukromý klíč zamknout pomocí přístupové fráze.

Soukromý klíč lze také hledat na standardních místech a jeho úplnou cestu lze zadat jako nastavení příkazového řádku (volba -i pro ssh). Nástroj ssh-keygen vytváří veřejný a soukromý klíč, vždy ve dvojicích.

SSH také podporuje ověřování na základě hesla, které je šifrováno automaticky generovanými klíči. V takovém případě by útočník mohl napodobit legitimní stranu serveru, požádat o heslo a získat ho ( útok typu man-in-the-middle ). To je však možné pouze v případě, že se obě strany nikdy předtím neoverily, protože SSH si pamatuje klíč, který strana serveru dříve používala. Klient SSH vyvolá varování před přijetím klíče nového, dříve neznámého serveru. Ověření heslem lze deaktivovat na straně serveru.

Používání

SSH se obvykle používá k přihlášení ke vzdálenému počítači a provádění příkazů, ale podporuje také tunelování , přesměrování portů TCP a připojení X11 ; může přenášet soubory pomocí souvisejících protokolů pro přenos souborů SSH (SFTP) nebo zabezpečených kopií (SCP). SSH používá model klient -server .

Klientský program SSH se obvykle používá k navazování připojení k démonu SSH přijímajícímu vzdálená připojení. Oba jsou běžně k dispozici na většině moderních operačních systémů , včetně macOS , většiny distribucí Linuxu , OpenBSD , FreeBSD , NetBSD , Solaris a OpenVMS . Verze systému Windows starší než Windows 10 verze 1709 ve výchozím nastavení SSH neobsahují. Existují proprietární , freeware a open source (např. PuTTY a verze OpenSSH, která je součástí Cygwin ) verzí různých úrovní složitosti a úplnosti. Správci souborů pro systémy podobné UNIX (např. Konqueror ) mohou pomocí protokolu FISH poskytovat GUI s rozděleným podoknem přetažením. Open source program Windows WinSCP poskytuje podobnou schopnost správy souborů (synchronizace, kopírování, vzdálené mazání) pomocí PuTTY jako back-endu. WinSCP i PuTTY jsou k dispozici zabalené pro spuštění přímo z jednotky USB bez nutnosti instalace na klientský počítač. Nastavení serveru SSH v systému Windows obvykle zahrnuje povolení funkce v aplikaci Nastavení. Ve Windows 10 verze 1709 je k dispozici oficiální port Win32 OpenSSH.

SSH je v cloud computingu důležitý pro řešení problémů s připojením, aby se předešlo problémům s bezpečností vystavení cloudového virtuálního stroje přímo na internetu. Tunel SSH může poskytovat zabezpečenou cestu přes internet, přes bránu firewall k virtuálnímu počítači.

IANA je přiřazen TCP portu 22, UDP portu 22 a SCTP kanálu 22 pro tento protokol. IANA uvedla standardní TCP port 22 pro servery SSH jako jeden ze známých portů již v roce 2001. SSH lze také provozovat pomocí protokolu SCTP než TCP jako protokolu transportní vrstvy orientované na připojení.

Historie a vývoj

Verze 1.x

V roce 1995 navrhl Tatu Ylönen , vědecký pracovník Helsinské technologické univerzity ve Finsku, první verzi protokolu (nyní nazývaného SSH-1 ), který byl vyvolán útokem na jeho univerzitní síť, který očichává heslo . Cílem SSH bylo nahradit dřívější protokoly rlogin , TELNET , FTP a rsh , které neposkytovaly silnou autentizaci ani nezaručovaly důvěrnost. Ylönen vydal svoji implementaci jako freeware v červenci 1995 a tento nástroj si rychle získal popularitu. Ke konci roku 1995 se uživatelská základna SSH rozrostla na 20 000 uživatelů v padesáti zemích.

V prosinci 1995 Ylönen založil SSH Communications Security za účelem prodeje a rozvoje SSH. Původní verze softwaru SSH používala různé části bezplatného softwaru , například GNU libgmp , ale pozdější verze vydané SSH Communications Security se vyvinuly ve stále proprietárnější software .

Odhadovalo se, že do roku 2000 počet uživatelů vzrostl na 2 miliony.

Verze 2.x

„Secsh“ byl oficiální název IETF ( Internet Engineering Task Force ) pracovní skupiny IETF odpovědné za verzi 2 protokolu SSH. V roce 2006 byla jako standard přijata revidovaná verze protokolu SSH-2 . Tato verze není kompatibilní s SSH-1. SSH-2 nabízí zabezpečení i vylepšení funkcí oproti SSH-1. Lepší zabezpečení například přináší výměna klíčů Diffie – Hellman a silná kontrola integrity pomocí ověřovacích kódů zpráv . Mezi nové funkce SSH-2 patří možnost spouštět libovolný počet relací shellu přes jedno připojení SSH. Vzhledem k nadřazenosti a popularitě SSH-2 nad SSH-1 podporují některé implementace jako libssh (v0.8.0+), Lsh a Dropbear pouze protokol SSH-2.

Verze 1.99

V lednu 2006, dlouho poté, co byla vytvořena verze 2.1, RFC 4253 specifikoval, že server SSH, který podporuje jak verze SSH 2.0, tak předchozí, by měl identifikovat jeho protoversion jako 1,99. Toto není skutečná verze, ale metoda k identifikaci zpětné kompatibility .

OpenSSH a OSSH

V roce 1999 se vývojáři, kteří chtěli mít k dispozici bezplatnou verzi softwaru, vrátili ke starší verzi 1.2.12 původního programu SSH, který byl naposledy vydán pod licencí open source . Z této kódové základny byl následně vyvinut OSSH Björn Grönvall. Krátce poté vývojáři OpenBSD rozdvojili Grönvallův kód a provedli na něm rozsáhlé práce, čímž vytvořili OpenSSH , který byl dodán s vydáním OpenBSD 2.6. Od této verze byla vytvořena větev „přenositelnosti“ pro přenos OpenSSH do jiných operačních systémů.

V roce 2005 byla OpenSSH nejpopulárnější implementací SSH, která ve výchozím nastavení přicházela ve velkém počtu operačních systémů. OSSH mezitím zastaral. OpenSSH je i nadále udržován a podporuje protokol SSH-2 s podporou SSH-1 z kódové základny ve verzi OpenSSH 7.6.

Využití

Příklad tunelování aplikace X11 přes SSH: uživatel „josh“ má „SSHed“ z lokálního počítače „foofighter“ na vzdálený počítač „tengwar“ pro spuštění xeyes .
Přihlášení do OpenWrt přes SSH pomocí PuTTY běžícího na Windows .

SSH je protokol, který lze použít pro mnoho aplikací napříč mnoha platformami, včetně většiny unixových variant ( Linux , BSD včetně Apple macOS a Solaris ) a také Microsoft Windows . Některé z níže uvedených aplikací mohou vyžadovat funkce, které jsou k dispozici nebo kompatibilní pouze s konkrétními klienty nebo servery SSH. Například použití protokolu SSH k implementaci VPN je možné, ale v současné době pouze s implementací serveru OpenSSH a klienta.

  • Pro přihlášení ke shellu na vzdáleném hostiteli (nahrazení Telnetu a rloginu )
  • Pro provedení jediného příkazu na vzdáleném hostiteli (nahrazení rsh )
  • Pro nastavení automatického (bez hesla) přihlášení ke vzdálenému serveru (například pomocí OpenSSH )
  • V kombinaci s rsync můžete efektivně a bezpečně zálohovat, kopírovat a zrcadlit soubory
  • Pro přeposílání portu
  • Pro tunelování (nezaměňovat s VPN , která směruje pakety mezi různými sítěmi nebo přemosťuje dvě vysílací domény do jedné).
  • Pro použití jako plnohodnotná šifrovaná VPN. Tuto funkci podporuje pouze server a klient OpenSSH .
  • Pro přesměrování X ze vzdáleného hostitele (možné prostřednictvím více mezihostitelů)
  • Pro procházení webu prostřednictvím šifrovaného připojení proxy s klienty SSH, které podporují protokol SOCKS .
  • Pro bezpečné připojení adresáře na vzdálený server jako souborový systém na místním počítači pomocí SSHFS .
  • Pro automatizované vzdálené monitorování a správu serverů prostřednictvím jednoho nebo více výše uvedených mechanismů.
  • Pro vývoj na mobilním nebo vestavěném zařízení, které podporuje SSH.
  • Pro zabezpečení protokolů pro přenos souborů.

Protokoly pro přenos souborů

Protokoly Secure Shell se používají v několika mechanismech přenosu souborů.

Architektura

Schéma binárního paketu SSH-2.

Protokol SSH-2 má vnitřní architekturu (definovanou v RFC 4251) s dobře oddělenými vrstvami, konkrétně:

  • Transport vrstva (RFC 4253), které obvykle běží nad TCP / IP. Tato vrstva zpracovává počáteční výměnu klíčů i autentizaci serveru a nastavuje ověřování šifrování, komprese a integrity. Vystavuje horní vrstvě rozhraní pro odesílání a přijímání paketů ve formátu prostého textu o velikosti až 32 768 bajtů (více může implementace povolit). Transportní vrstva také zajišťuje výměnu klíčů, obvykle po přenosu 1 GB dat nebo po uplynutí 1 hodiny, podle toho, co nastane dříve.
  • Vrstva autentizace uživatele (RFC 4252). Tato vrstva zpracovává ověřování klientů a poskytuje řadu metod ověřování. Ověřování je řízeno klientem : když je někdo vyzván k zadání hesla, může to být výzva klienta SSH, nikoli server. Server pouze reaguje na požadavky klienta na ověření. Mezi široce používané metody ověřování uživatelů patří následující:
    • heslo : metoda přímého ověřování heslem, včetně zařízení umožňujícího změnu hesla. Ne všechny programy tuto metodu implementují.
    • publickey : metoda ověřování na základě veřejného klíče , obvykle podporující alespoň páry klíčů DSA , ECDSA nebo RSA , přičemž další implementace také podporují certifikáty X.509 .
    • klávesnice-interaktivní (RFC 4256): univerzální metoda, kdy server odešle jednu nebo více výzev k zadání informací a klient je zobrazí a odešle zpět odpovědi zadané uživatelem. Používá se k zajištění jednorázového ověření hesla, jako je S/Key nebo SecurID . Používají ho některé konfigurace OpenSSH, když je PAM základním poskytovatelem autentizace hostitele k efektivnímu poskytování autentizace heslem, což někdy vede k nemožnosti přihlášení pomocí klienta, který podporuje pouze jednoduchou metodu autentizace heslem .
    • Metody autentizace GSSAPI, které poskytují rozšiřitelné schéma pro provádění autentizace SSH pomocí externích mechanismů, jako je Kerberos 5 nebo NTLM , poskytující jednotné přihlašování relacím SSH. Tyto metody jsou obvykle implementovány komerčními implementacemi SSH pro použití v organizacích, ačkoli OpenSSH má funkční implementaci GSSAPI.
  • Spojení vrstva (RFC 4254). Tato vrstva definuje koncept kanálů, kanálových požadavků a globálních požadavků, pomocí kterých jsou služby SSH poskytovány. Jedno připojení SSH může hostovat více kanálů současně, přičemž každý přenáší data v obou směrech. Požadavky na kanály se používají k přenosu mimo-pásmových dat specifických pro kanál, jako je změněná velikost okna terminálu nebo výstupní kód procesu na straně serveru. Každý kanál navíc provádí vlastní řízení toku pomocí velikosti přijímacího okna. Klient SSH požaduje, aby byl port na straně serveru předán pomocí globálního požadavku. Mezi standardní typy kanálů patří:
    • shell pro terminály, požadavky SFTP a exec (včetně přenosů SCP)
    • direct-tcpip pro připojení přesměrovaná mezi klientem a serverem
    • forwarded-tcpip pro přesměrovaná připojení server-klient
  • Záznam SSHFP DNS (RFC 4255) poskytuje otisky prstů veřejného hostitele za účelem pomoci při ověřování pravosti hostitele.

Tato otevřená architektura poskytuje značnou flexibilitu a umožňuje použití SSH pro různé účely mimo zabezpečený shell. Samotná funkčnost transportní vrstvy je srovnatelná s Transport Layer Security (TLS); vrstva autentizace uživatele je vysoce rozšiřitelná pomocí vlastních metod autentizace; a vrstva připojení poskytuje možnost multiplexovat mnoho sekundárních relací do jediného připojení SSH, což je funkce srovnatelná s BEEP a není k dispozici v TLS.

Navzdory populární mylné představě není SSH implementací Telnetu s kryptografií poskytovanou vrstvou SSL (Secure Sockets Layer) .

Algoritmy

Zranitelnosti

SSH-1

V roce 1998 byla v SSH 1.5 popsána zranitelnost, která umožňovala neoprávněné vkládání obsahu do šifrovaného proudu SSH z důvodu nedostatečné ochrany integrity dat z CRC-32 používané v této verzi protokolu. Oprava známá jako SSH Compensation Attack Detector byla zavedena do většiny implementací. Mnoho z těchto aktualizovaných implementací obsahovalo novou zranitelnost přetečení celého čísla, která útočníkům umožňovala spouštět libovolný kód s oprávněními démona SSH, obvykle root.

V lednu 2001 byla objevena chyba zabezpečení, která útočníkům umožňuje upravit poslední blok relace šifrované pomocí IDEA . Ve stejný měsíc byla objevena další chyba zabezpečení, která umožnila škodlivému serveru přeposlat ověření klienta na jiný server.

Vzhledem k tomu, že SSH-1 má inherentní konstrukční chyby, které ho činí zranitelným, je nyní obecně považován za zastaralý a mělo by se mu zabránit výslovným vypnutím záložního SSH-1. Většina moderních serverů a klientů podporuje SSH-2.

Obnova prostého textu CBC

V listopadu 2008 byla u všech verzí SSH objevena teoretická zranitelnost, která umožňovala obnovu až 32 bitů prostého textu z bloku šifrového textu, který byl šifrován pomocí tehdejšího standardního výchozího šifrovacího režimu, CBC . Nejjednodušším řešením je použít CTR , režim čítače, místo režimu CBC, protože to činí SSH odolným vůči útoku.

Možné chyby zabezpečení

28. prosince 2014 Der Spiegel zveřejnil utajované informace, které unikl informátorovi Edwardu Snowdenovi, což naznačuje, že Národní bezpečnostní agentura může být schopna dešifrovat nějaký provoz SSH. Technické detaily spojené s takovým procesem nebyly zveřejněny. Analýza hackerských nástrojů CIA v roce 2017 BothanSpy a Gyrfalcon naznačila, že samotný protokol SSH nebyl ohrožen.

Dokumentace standardů

Následující publikace RFC pracovní skupiny IETF „secsh“ dokumentují SSH-2 jako navrhovaný internetový standard .

  • RFC  4250 - Čísla přiřazená protokolu Secure Shell (SSH)
  • RFC  4251 - Architektura protokolu Secure Shell (SSH)
  • RFC  4252 - ověřovací protokol Secure Shell (SSH)
  • RFC  4253 - Protokol transportní vrstvy Secure Shell (SSH)
  • RFC  4254 - protokol připojení Secure Shell (SSH)
  • RFC  4255 - Použití DNS k bezpečnému publikování otisků klíčů Secure Shell (SSH)
  • RFC  4256 - Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
  • RFC  4335 - The Secure Shell (SSH) Session Channel Break Extension
  • RFC  4344 - Režimy šifrování transportní vrstvy Secure Shell (SSH)
  • RFC  4345 - Vylepšené režimy Arcfour pro protokol transportní vrstvy Secure Shell (SSH)

Později byl upraven a rozšířen o následující publikace.

  • RFC  4419 -Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol (březen 2006)
  • RFC  4432 - RSA Key Exchange for Secure Shell (SSH) Transport Layer Protocol (březen 2006)
  • RFC  4462 -Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol (May 2006)
  • RFC  4716 - formát souboru veřejného klíče Secure Shell (SSH) (listopad 2006)
  • RFC  4819 - Subsystém veřejného klíče Secure Shell (březen 2007)
  • RFC  5647 - AES Galois Counter Mode for Secure Shell Transport Layer Protocol (srpen 2009)
  • RFC  5656 - Integrace algoritmu eliptické křivky do transportní vrstvy Secure Shell (prosinec 2009)
  • RFC  6187 - X.509v3 Certificates for Secure Shell Authentication (březen 2011)
  • RFC  6239 - Suite B Cryptographic Suites for Secure Shell (SSH) (květen 2011)
  • RFC  6594 -Použití algoritmu SHA-256 s RSA, algoritmem digitálního podpisu (DSA) a eliptické křivky DSA (ECDSA) v záznamech zdrojů SSHFP (duben 2012)
  • RFC  6668 -SHA-2 Data Integrity Verify for the Secure Shell (SSH) Transport Layer Protocol (červenec 2012)
  • RFC  7479 - Ed25519 SSHFP Resource Records (březen 2015)
  • RFC  5592 - Secure Shell Transport Model pro protokol SNMP (Simple Network Management Protocol) (červen 2009)
  • RFC  6242 - Použití protokolu NETCONF přes Secure Shell (SSH) (červen 2011)
  • draft-gerhards-syslog-transport-ssh-00-transportní mapování SSH pro SYSLOG (červenec 2006)
  • draft-ietf-secsh-filexfer-13-SSH File Transfer Protocol (červenec 2006)

Kromě toho OpenSSH projektu zahrnuje několik specifikace dodavatele Protocol / rozšíření:

Viz také

Reference

Další čtení

externí odkazy