Od verze 5.4, která vyšla v březnu 2010, podporuje OpenSSH používání certifikátů pro ověřování platnosti serverových i uživatelských SSH klíčů. Nejedná se o plnohodnotné X.509 certifikáty, které známe například z protokolu SSL/TLS, i když základní myšlenka je stejná – namísto přímého ověřování jednotlivých entit svěříme svou důvěru certifikační autoritě. Jejím úkolem je ověřit, že entita vlastnící daný klíč je tou, za kterou se vydává a toto stvrdit svým podpisem na certifikátu. Takový certifikát může ještě obsahovat omezení, za jakých okolností je platný, tak aby například certifikát serveru server.example.com nebyl platný, pokud ho použije server jiného jména.
Vytvoření certifikační autority (CA)
I přes vznešený název není certifikační autorita nic jiného, než běžná dvojice veřejného a soukromého SSH klíče:
$ ssh-keygen -t rsa -b 4096 -C exampleCA -f key-exampleCA
Důvěryhodnost celého systému závisí na zabezpečení privátního klíče certifikační autority. Měli bychom tedy volit opravdu silné heslo k šifrování privátního klíče. Nebo ještě lépe privátní klíč vůbec nemít na disku, bude totiž potřeba jen při vystavování certifikátů, což se neděje příliš často.
Vytvoření serverových certifikátů
K vytvoření certifikátu je třeba bezpečně dopravit na společný počítač zároveň privátní klíč certifikační autority i veřejný klíč, který má být podepsán. Vlastní podepsání serverových klíčů provedeme takto:
$ ssh-keygen -s key-exampleCA -I server.example.com -h \
-n server.example.com,1.2.3.4,2001::1:2:3 \
ssh_host*.pub
Enter passphrase:
Signed host key ssh_host_dsa_key-cert.pub: id "server.example.com"
serial 0 for server.example.com,1.2.3.4,2001::1:2:3 valid forever
Signed host key ssh_host_ecdsa_key-cert.pub: id "server.example.com"
serial 0 for server.example.com,1.2.3.4,2001::1:2:3 valid forever
Signed host key ssh_host_rsa_key-cert.pub: id "server.example.com"
serial 0 for server.example.com,1.2.3.4,2001::1:2:3 valid forever
Pro vystavování serverových certifikátů je klíčové použití přepínače -h, jinak je vystaven uživatelský certifikát, který SSH server odmítne. Přepínač -I označuje identifikátor klíče, to je řetězec, který se mimo jiné vypíše do logu při pokusu o přihlášení. Nepovinný přepínač -n omezuje použití certifikátu na uvedená jména serverů (v originále principals). Pokud jej neuvedeme, bude certifikát platný globálně. Manuálová stránka programu ssh-keygen uvádí další možná omezení, včetně například omezení doby platnosti certifikátu.
Vygenerované certifikáty nyní přeneseme na server, preferovaně do adresáře /etc/ssh. Na rozdíl od serverových klíčů, které jsou SSH serverem automaticky načteny, musíme u certifikátů explictně vyžádat jejich načtení přidáním následujících řádků do souboru sshd_config:
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub HostCertificate /etc/ssh/ssh_host_dsa_key-cert.pub # Vynechte následující řádek, pokud ECDSA klíče nepoužíváte HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
Po reloadu nebo restartu by měl být server připraven. Může se ale stát, že server odmítne certifikáty načíst. Mně se to stalo v případě, kdy jsem se pokoušel nahrát certifikát z nové verze balíku OpenSSH do staršího serveru. Ve vydání OpenSSH 5.6 byl totiž zaveden nový formát certifikátu, který je se starými servery nekompatibilní. Řešení problému je dvojí, buď vygenerovat certifikát použitím utilitky ssh-keygen ze starší verze OpenSSH, nebo pomocí nedokumentované funkce vynutit generování staršího formátu certifikátu v nové verzi:
$ ssh-keygen -s … -t ssh-rsa-cert-v00@openssh.com ssh_host_rsa_key.pub $ ssh-keygen -s … -t ssh-dss-cert-v00@openssh.com ssh_host_dsa_key.pub
Ověřování serverových certifikátů
Server máme nakonfigurován, zbývá nastavit klienta. V souboru known_hosts odstraňte nebo zakomentujte všechny záznamy se starými klíči serveru, které už nebudou potřeba. Dále do souboru vložte, preferovaně na začátek, veřejný klíč certifikační autority:
@cert-authority * ssh-rsa AAAAB3…NN exampleCA
Před klíč, získaný ze souboru key-exampleCA.pub připíšeme atribut @cert-authority a hvězdičku. Ta zde nahrazuje jméno konkrétního serveru a znamená tedy, že klíč CA platí pro jakýkoli server, který se prokáže platným certifikátem.
Na tomto místě je dobré se zmínit, že existuje také globální seznam známých serverů. Ten se nachází v souboru /etc/ssh/ssh_known_hosts. Umístíme-li klíč CA tam, bude CA důvěryhodná pro všechny místní uživatele.
Pokud jste podle minulého dílu nastavili proměnnou klienta HostKeyAlgorithms na ssh-rsa a ssh-dss, toto nastavení znemožňuje přijetí certifikátu. Volbu tedy buď zakomentujte, nebo doplňte formáty SSH certifikátů, které najdete v manuálové stránce ssh_config(5), například takto:
HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss
Nyní se zkuste přihlásit. Přidejte přepínač -v a sledujte, jak ověření serveru probíhá:
$ ssh -v server.example.com … debug1: Server host key: RSA-CERT 33:74:2d:3b:12:79:a4:bc:69:b4:62:9b:ee:8d:19:c4 debug1: Host 'server.example.com' is known and matches the RSA-CERT host certificate. debug1: Found CA key in /home/user/.ssh/known_hosts:1 …
Uživatelské certifikáty
Princip certifikátů funguje stejně dobře i s uživatelskými klíči. Také uživatelský klíč můžeme podepsat certifikační autoritou. Nepovinný přepínač -n tentokrát určuje uživatelské jméno, pro které je daný certifikát platný.
$ ssh-keygen -s key-exampleCA -I user@example.com \
-n user,root id_dsa.pub
Enter passphrase:
Signed user key id_dsa-cert.pub: id "user@example.com" serial 0 for user,root valid forever
Ponecháme-li certifikátu výchozí jméno, OpenSSH ho automaticky najde a načte:
$ ssh-add id_dsa Identity added: id_dsa (id_dsa) Certificate added: id_dsa-cert.pub (user@example.com)
Akceptaci certifikátů na straně serveru zajistíme tak, že do souboru ~/.ssh/authorized_keys vložíme veřejný klíč CA, opatřený značkou cert-authority:
cert-authority ssh-rsa AAAAB3…NN exampleCA
Centralizujeme
Uživatelské certifikáty můžeme využít i jiným, zajímavějším způsobem. Klíč certifikační autority je možné zadat globálně SSH serveru. Server pak automaticky povolí přihlášení platnému certifikátu, jehož pole principals odpovídá požadovanému uživatelskému účtu, aniž by vůbec musel existovat soubor ~/.ssh/authorized_keys. Stačí k tomu veřejný klíč CA někam nakopírovat, například do /etc/ssh/key-exampleCA.pub, a do konfiguračního souboru serveru přidat volbu:
TrustedUserCAKeys /etc/ssh/key-exampleCA.pub
Nemá-li uživatelský certifikát vyplněno jméno principals, nemůže se pomocí centrální autority přihlásit. Seznam principálů, kteří se mohou přihlásit, může být dále omezen v souboru, na který ukazuje konfigurační direktiva AuthorizedPrincipalsFile.
Revokujeme
Nedílnou součástí vydávání jakýchkoli certifikátů je i jejich zneplatnění – revokace. K té by mělo dojít, kdykoli klíč opatřený příslušným certifikátem pozbyl svého významu, nebo byl kompromitován.
Poměrně snadná je revokace serverového certifikátu. Stačí revokovat příslušný serverový klíč tak, jak jsme si ukázali už v minulém díle. Revokovaný klíč vložíme do souboru známých serverů a opatříme tagem @revoked, popřípadě i hvězdičkou na místě jména serveru. Revokací klíče pozbude platnosti i certifikát, který byl pro klíč vystaven a při pokusu o jeho použití vyhlásí SSH klient poplach:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REVOKED HOST KEY DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA-CERT host key for server.example.com is marked as revoked. This could mean that a stolen key is being used to impersonate this host. RSA-CERT host key for server.example.com was revoked and you have requested strict checking. Host key verification failed.
U uživatelských certifikátů je situace složitější. Zatímco nevhodné uživatelské klíče stačí odstranit ze souboru ~/.ssh/authorized_keys, při použití certifikátů můžeme takto zneplatnit pouze všechny certifikáty vydané příslušnou CA najednou. Jediná možnost selektivní revokace konkrétních uživatelských klíčů, které mají vystaven důvěryhodný certifikát, spočívá v konfigurační volbě serveru zvané RevokedKeys. Ta ukazuje na soubor obsahující revokované uživatelské klíče. Tento soubor je čten při každém pokusu o přihlášení a obsahuje-li klíč, kterým se uživatel snaží hlásit, server přihlášení odmítne a do syslogu poznamená:
sshd: error: WARNING: authentication attempt with a revoked RSA key e9:…:87
K dobrým praktikám při vydávání certifikátů patří také časové omezení jejich platnosti. Po uplynutí časové platnosti certifikátu se stane nepoužitelným a k němu příslušející klíč tedy můžeme bez obav odstranit z revokačního seznamu. Příliš krátké časové omezení certifikátů ale zase naopak zvyšuje nároky na distribuci aktuálních certifikátů, jejich podepisování a tím také ochranu privátního klíče CA. Je tedy vždy potřeba najít rozumný kompromis.
Závěr
V používání SSH certifikátů osobně vidím velký přínos. Především serverové certifikáty představují zvýšení bezpečnosti a usnadnění správy seznamů známých serverů v podstatě bez negativních aspektů. Na rozdíl od uložení klíče v systému DNSSEC není celý systém závislý na poměrně komplexní hierarchii podpisů DNS zón. Není ale žádný problém provozovat oba systémy současně a vytěžit z každého jeho pozitiva.
I uživatelské certifikáty si jistě své místo na slunci najdou, především v cetralizované variantě. Před jejich nasazením a používáním je ale třeba nějakým způsobem vyřešit distribuci seznamu revokovaných klíčů. Masivnímu rozšíření uživatelských certifikátů také jistě brání nepodpora v alternativních klientech, zejména PuTTY.
V příštím, nejspíše závěrečném díle seriálu o zajímavých vlastnostech OpenSSH si rozebereme různé scénáře použití OpenSSH, včetně těch méně tradičních. Pokusíme se omezit množinu akcí, které může klient provádět, a jistě dojde i na nějaké tipy a triky.
ČLÁNKY DO MAILU