DNSSEC jako bezpečné uložiště SSH klíčů

O serverových klíčích

K prokazování své identity používá server princip elektronického podpisu. Během navazování SSH spojení server pošle klientovi svůj veřejný SSH klíč a podpisem prokáže, že vlastní i příslušný privátní klíč.

Serverové klíče jsou uloženy v adresáři /etc/ssh, jeden pár pro každý algoritmus, který server podporuje. Technicky jsou úplně stejné jako uživatelské klíče, které jsme si představili v prvním díle seriálu. Jediný rozdíl je v tom, že serverový klíč nesmí být šifrovaný, aby jej mohl SSH server načíst bez asistence administrátora. Vygenerovány jsou obvykle spouštěcími skripty distribuce, těsně před prvním spuštěním SSH serveru.

Ověření serverového klíče

SSH klient by při navázání spojení měl ověřit, zda veřejný klíč, kterým se server prokázal, skutečně patří serveru, se kterému se snaží spojit. Základní způsob takového ověření spočívá v tom, že si každý SSH klient udržuje databázi známých SSH serverů v souboru ~/.ssh/known_hosts. Navážeme-li poprvé spojení s neznámým serverem, vypíše SSH klasický dotaz:

The authenticity of host 'server.example.com (1.2.3.4)' can't be established.
RSA key fingerprint is bf:14:ce:69:11:54:08:da:6c:fe:3b:aa:34:18:45:e8.

Are you sure you want to continue connecting (yes/no)?

Uživatel by v tuto chvíli měl správně ověřit otisk z nezávislého zdroje. Pokud odpoví yes, uloží se do databáze známých serverů jméno serveru, jeho IP adresa a jemu odpovídající otisk klíče. Při příštím přihlášení se již klient na nic neptá, dokud se otisk klíče serveru shoduje s uloženým otiskem. Jak se shodovat přestane, klient vyhlásí poplach a odmítne pokračovat:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
17:06:28:c4:eb:a8:ed:e6:de:48:fe:ab:00:61:c7:b2.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/user/.ssh/known_hosts:12
RSA host key for server.example.com has changed and you have requested strict checking.
Host key verification failed.

Smazání souboru ~/.ssh/known_hosts je asi nejčastější řešení a zároveň vůbec to nejhorší, co může uživatel v dané situaci udělat. Přijde tím o kompletní databázi otisků serverů, včetně těch, které se nezměnily. Lepším řešením je – po nezávislém potvrzení, že změna klíče je legitimní a očekávaná – vymazat ze souboru pouze řádek, označený jako Offending key, ve výše uvedeném případě tedy řádek číslo 12. Můžeme také řádek v souboru nechat, pouze před něj připsat klíčové slovo @revoked a jméno serveru nahradit hvězdičkou. Tím dáme najevo, že daný klíč je revokovaný, a setká-li se s ním klient u jakéhokoli serveru, vyhlásí poplach.

Ukládání serverových klíčů v DNSSEC

Úvodní ověření klíče serveru je vcelku obtížné. Málokterý správce skutečně publikuje otisky klíče tak, aby je bylo možné nezávisle ověřit, například na zabezpečené webové stránce. Celá důvěra v bezpečné spojení tak stojí a padá na tom, že první spojení k serveru, kdy došlo k uložení otisku klíče, nebylo podvrženo. Přitom existuje poměrně snadné řešení – publikovat otisky SSH klíčů v systému DNS. Systém DNSSEC zaručí potřebnou autenticitu dat, takže pro útočníka je téměř nemožné DNS data podvrhnout.

Pro ukládání otisků SSH klíčů v DNS byly zavedeny nové typy DNS záznamů, zvané SSHFP. Vygenerujeme je z veřejných klíčů serveru pomocí:

$ ssh-keygen -r server.example.com
server.example.com IN SSHFP 1 1 41a69d4df60e232d76ea2ba8ee174c4a864e1718
server.example.com IN SSHFP 2 1 ea800771358c5a076b54857a7cf65e732491d575

Zadané jméno serveru na příkazovém řádku ovlivňuje pouze první sloupec vygenerovaných DNS záznamů. Vlastní otisky jsou vygenerovány z veřejných klíčů serveru, standardně uložených na cestě /etc/ssh/ssh_host_[rd]sa_key.pub. Pomocí příznačně nazvané utilitky SSHFP je možné získat SSHFP záznamy i z jiných zdrojů, například ze souboru known_hosts, nebo přes síť (což nemusí být vždy zcela bezpečné). Bohužel, specifikace záznamu SSHFP dosud nebyla rozšířena o podporu pro ECDSA klíče, jejich otisky tedy prozatím není možné do DNS uložit.

Získané záznamy je nyní potřeba vložit do zónového souboru domény, ve které je server umístěn. Poté je třeba zónový soubor znovu podepsat a vystavit v systému DNS. To za vás udělá ten, u koho hostujete domény. Pokud své domény hostujete svépomocí, dočtete se konkrétní postup ve starším článku DNSSEC na autoritativním serveru. Správné vystavení otisků prověříme příkazem dig:

$ dig +dnssec server.example.com SSHFP

; <<>> DiG 9.7.3 <<>> +dnssec server.example.com SSHFP
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44930
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 6
…
;; ANSWER SECTION:
server.example.com.     3600    IN      SSHFP   2 1 EA800771358C5A076B54857A7CF65E732491D575
server.example.com.     3600    IN      SSHFP   1 1 41A69D4DF60E232D76EA2BA8EE174C4A864E1718
server.example.com.     3600    IN      RRSIG   …
…

Důležitá je přítomnost flagu (příznaku) ad – authenticated data, který sděluje, že data byla rekurzivním DNS serverem validována. Nemáte-li k dispozici validující DNS resolver, můžete použít jeden z veřejných validujících serverů sdružení CZ.NIC.

Validace SSHFP záznamů v SSH klientovi

Zbývá poslední krok, nakonfigurovat klienta, protože ve výchozím nastavení je ověřování otisků klíčů v DNS vypnuto. Dále, pokud se připojujeme k OpenSSH serveru verze 5.7 nebo vyšší, musíme zrušit preferenci ECDSA klíčů, jejichž otisky bohužel zatím do DNS umisťovat neumíme. Do uživatelského konfiguračního souboru ~/.ssh/config, nebo globálního souboru /etc/ssh/ssh_config přidáme:

VerifyHostKeyDNS yes
HostKeyAlgorithms ssh-rsa,ssh-dss

Teď můžeme konečně vyzkoušet připojení s ověřením otisku v DNS. Odstraňte, nebo zakomentujte záznam pro server ve svém souboru known_hosts a zkuste se připojit.

Pokud přihlášení proběhlo bez problémů, gratuluji, vaše verze OpenSSH a glibc obsahují ty správné patche. Může se však také stát, že SSH klient požádá o potvrzení autenticity, které bude jen obohacené o větu, oznamující nález platných podpisů:

The authenticity of host 'server.example.com (1.2.3.4)' can't be established.
RSA key fingerprint is aa:55:cc:9c:a5:c6:1b:f1:a5:d2:be:eb:7e:1c:53:05.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

V takovém případě SSH klient sice objevil DNS záznamy s platnými otisky, ale nebyl schopen zjistit, zda jsou záznamy zabezpečeny systémem DNSSEC. Pokud není chyba v systému DNSSEC, což jsme ověřili příkazem dig výše, znamená to, že OpenSSH není schopno prostřednictvím knihovních funkcí knihovny glibc získat informaci o ověření platnosti DNSSEC podpisu. Můžeme mu zkusit pomoci přidáním následujícího řádku do souboru  /etc/resolv.conf:

options edns0

Pokud ani to nepomůže, nezbývá než aktualizovat na nejnovější verze glibc a OpenSSH. Moje zkušenosti, včetně zkušeností sesbíraných z webu, shrnuje následující tabulka:

Budu rád, když se podělíte v diskuzi o zkušenosti s nastavením dalších distribucí. Pro účely testování jsem objevil jeden veřejně přístupný SSH server s SSHFP záznamy a zároveň DNSSEC zabezpečením na adrese s0.barwen.ch. Protože autentizace serveru probíhá před autentizací klienta, není k takovém testování třeba vlastnit účet na příslušném serveru.

Obsah příští části

Ukládání otisků SSH klíčů do systému DNS je velmi dobrou technikou ke zvýšení bezpečnosti i komfortu používání SSH. Téma serverových klíčů ale není tímto článkem zcela vyčerpáno. Příště se podíváme na certifikáty, další možnost, jak spravovat otisky nejen serverových, ale i klientských SSH klíčů.