Konec starého protokolu SSHv1?
Jednou z nejdiskutovanějších změn, která přišla v této verzi, je kompletní zakázání protokolu SSH první verze (SSHv1) během kompilace. Tento protokol je zastaralý, nové servery jej ve výchozí konfiguraci nenabízejí, ale jenom možnost jej povolit a jeho přítomnost je bezpečnostní riziko.
Když se toto téma poprvé objevilo, mnoho uživatelů argumentovalo, že stále potřebují spravovat staré nebo vestavěné systémy vybavené pouze protokolem SSHv1. Ten je stále bezpečnější než nezabezpečený telnet.
S těmito požadavky a s novinkami od vývojářů se musí vypořádat distribuce, které chtějí držet krok, ale zároveň nechtějí rozbíjet zpětnou kompatibilitu s ostatními distribucemi (a s výše zmíněnými vestavěnými zařízeními) a nechtějí nutit uživatele hledat zbytečně náročná řešení.
Protože byla poptávka po klientovi, u kterého dává smysl podporu SSHv1 ponechat, rozhodli jsme se ve Fedoře přidat balíček openssh-clients-ssh1 poskytující alternativní klientské aplikace ( ssh1, ssh-keygen1 a scp1) sestavené s podporou SSHv1, které použití protokolu s minimem úsilí umožňují a zároveň nehrozí jejich použití nevědomky.
Povolit přihlášení roota?
Pokud se za posledních 10 let na některé emailové konferenci nebo v bugzille objevil návrh na zakázání vzdáleného přihlášení superuživatele přes SSH, objevovaly se podobné emoce jako u zakazování protokolu SSHv1. Mám pocit, že všichni cítí, že toto na produkční server prostě nepatří, protože riziko uhodnutí hesla je příliš velké a roboti útočí většinou právě na tento účet.
Ale co když stroj žádného jiného uživatele po instalaci nemá? Příkladem mohou být dnes oblíbená cloudová řešení a různé minimální instalace. Výchozí zákaz přihlášení roota je stále trochu strašákem, protože být odstřižen od vlastního serveru bez možnosti použití lokální konzole není nic příjemného.
Vývojáři opět částečně vyslechli uživatele a nová výchozí hodnota pro nastavení PermitRootLogin se mění z yes na prohibit-password, čímž efektivně brání útokům na heslo superuživatele a zároveň neznemožňuje přihlášení legitimního správce ve výchozím nastavení (pokud si tedy předem nastaví přístupový klíč). V poslední verzi bylo navíc toto nastavení vylepšeno a nyní zakazuje veškeré přihlášení heslem (zbývá tedy pouze veřejný klíč, HostBased a GSSAPI).
Zakázání historických algoritmů protokolu SSHv2
Protokol SSHv2 již nezávisí na jediném algoritmu, jako tomu bylo u protokolu prvního, ale i tak zde existují algoritmy, které jsou s postupem času zastaralé a potenciálně zranitelné, nebo již déle nedoporučované.
Jedním z těchto algoritmů je výměna klíčů diffie-hellman-group1-sha1, která používá prvočísla pevné délky 1024 bitů a je tedy teoreticky napadnutelná útokem typu Logjam za pomoci výpočetní síly třeba některé z národních agentur.
Druhým, ve výchozím nastavení zakázaným algoritmem, jsou klíče ssh-dss, a certifikáty ssh-dss-cert-*. Tyto klíče jsou postaveny na algoritmu DSA, který byl vytvořen Národním institutem standardů a technologií (NIST) v USA v roce 1991 a je velmi citlivý na zdroj náhodných čísel. Je stále schvalovaný, již ne preferovaný.
Poslední zastaralá věc jsou certifikáty v00, jejichž podpora byla v této verzi odebrána na úkor nové verze v01 pro celkové zjednodušení kódu.
Interoperabilita s legacy implementacemi
Výše zmíněné algoritmy nebyly z implementace vyřazeny úplně, ale nejsou nabízeny jako výchozí. V případě, že uživatel se potřebuje připojit na nějaký server podporující pouze tyto algoritmy a není schopný navázat spojení s novějšími, existuje jednoduché řešení.
To je popsáno na samostatné stránce popisující novou možnost výběru algoritmů na příkazové řádce. Použití prefixu + umožňuje přidat algoritmus do nabízeného seznamu, bez nutnosti předefinovat původní sadu. Například ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@127.0.0.1 pro připojení za použití prvního zmíněného algoritmu výměny klíčů.
Bezpečnost
Na začátku tohoto roku bylo bezpečnostních oznámení v OpenSSH relativně poskrovnu, ale v posledních verzích se objevuje jedna za druhou. Výjimkou není ani tato, kde je jich opraveno hned několik. Některé existují již velmi dlouho a jiné vznikly jako chyba v posledních verzích.
První z nich je CVE-2015–5600, která za použití dlouhého seznamu autentizačních metod obsahujících více hodnot keyboard-interactive, umožňovala obejít omezeni maximálního počtu pokusů o autentizaci heslem, které je nastavené pomocí volby MaxAuthTries.
Další výrazný problém se objevil v přístupových právech k TTY na serveru, která byla omylem zapisovatelná pro všechny uživatele systému. To umožnilo lokálnímu útočníku zapisovat zprávy přihlášeným uživatelům, včetně escape sekvencí terminálu. Tato chyba vznikla až ve verzi 6.8 a tak mnoho distribucí není ohroženo.
Poslední problém, který existoval pouze v portable verzi, je spojený s použitím PAM (Pluggable Authentication Module). Pokud se útočníkovi podařilo kompromitovat předautentizační proces ke spuštění cizího kódu a měl validní přístupové údaje k systému, mohl se vydávat za jiné uživatele systému.
Nové funkce
V poslední verzi přibylo několik nových nastavení. Mezi nimi PubkeyAcceptedKeyTypes a HostKeyAlgorithms, které definují seznam typů klíčů a certifikátů použitelných pro autentizaci na straně klienta a akceptovatelných na straně serveru.
Dále byly rozšířeny volby Ciphers, MACs, KexAlgorithms, HostKeyAlgorithms, PubkeyAcceptedKeyTypes a HostbasedKeyTypes o možnost přidání seznamu algoritmů místo nahrazení celého původního seznamu. Toto je využíváno u výše zmíněného zastarávání algoritmů.
Poslední změnou je již výše popisovaná nová hodnota prohibit-password pro nastavení PermitRootLogin, která je méně zavádějící než původní without-password.
Opravy chyb
Bylo identifikováno a opraveno několik problémů, které bránily použití některých typů smart karet pro autentizaci ke vzdálenému serverů. Vylepšena byla také kompatibilita s Cisco a PuTTY a zároveň došlo k několika dokumentačních změnám.
V tomto směru tedy pouze evoluce v mezích zákona. Osobně jsem doufal, že se do tohoto velkého vydání podaří dostat další opravy.
Vyzkoušejte si novinky
Nové OpenSSH bude k dispozici v následující Fedoře 23 Beta.
