/Admin corner- Certificaten in SSH

Dankzij public key authentication en de ssh-agent hoef je geen 158 wachtwoorden per dag meer in te kloppen. Je unlockt eenmaal je private key en daarna log je meteen in op alle systemen waar de bijbehorende public key staat. Best handig, maar het beheer van die public key wordt algauw een administratieve nachtmerrie…

Beheer je maar een paar systemen, dan kopieer je de public key snel naar de benodigde user accounts. Lastiger wordt het als je verantwoordelijk bent voor honderden servers. Of als je tientallen collega’s toegang moet verlenen tot allerlei user accounts. Keys handmatig kopiëren is dan geen optie meer, tenzij je graag apenwerk uitvoert. Configuration management tools kunnen je het lastige werk uit handen nemen, maar zulke tools zijn niet altijd voorhanden. Dan maar ad hoc scripts beginnen schrijven om keys op nieuwe servers te installeren? Dat kan behoorlijk tijdrovend zijn en de kans op fouten blijft reëel! Maar wist je dat je ook certificaten kunt gebruiken voor ssh-authenticatie?

CERTIFICATEN
De certificaten in ssh zijn een vereenvoudigde versie van de bekende OpenSSL/X.509-certificaten, die onder andere door web- of mailservers voor encryptie worden gebruikt. Je moet dus eerst een public/private-keypair aanmaken dat als Certificate Authority dienst doet:

$ ssh-keygen -f ./ca_key -C ‘My CA private key’

Uiteraard beveilig je de private key met een voldoende lange passphrase! Nu kun je certificaten aanmaken door de public key van een gebruiker te ondertekenen met de CA private key. Bijvoorbeeld:

$ ssh-keygen -s ./ca_key
-n user1 -I user1 ./id
rsa_user1.pub
Signed user key id_rsa
user1-cert.pub: id
“user1” valid forever

Met de optie -n bepaal je als welke gebruiker je met het certificaat op het remote systeem mag inloggen. Dit moet uiteraard een bestaande gebruikersnaam zijn; anders is het certificaat vrij nutteloos. Achter de -I-optie geef je een zogenoemde key identifier op. Dat is een vrij te kiezen tekst die aangeeft voor wie of wat het certificaat dient. Het certificaatbestand bezorg je nu aan de gebruiker. Op de ssh-server moet je authenticatie via certificaten wel nog expliciet inschakelen. Voeg daarom de volgende optie toe aan sshd_config:

TrustedUserCAKEYS /etc
ssh/trusted_ca_keys

En plaats de public key van het CA-keypair in het hierboven vermelde bestand:

$ cat ./ca_key.pub >> etc/ssh/trusted_ca_keys

Om het certificaat te testen zet je de public key van jouw gebruiker even in commentaar in het authorized_keys-bestand op de remote server. Want zo lang de public daarin staat, heeft de sshclient het certificaat natuurlijk niet nodig om in te loggen! Werkt dit naar behoren? Dan hoef je jouw public key niet meer naar alle systemen te kopiëren. Vanaf nu log je gewoon overal in met jouw certificaat.

BEPERKINGEN
Het certificaat hierboven was bruikbaar voor één bepaalde gebruiker op alle systemen die de public key van onze CA vertrouwen. Maar je kunt ook diverse gebruikers specificeren, gescheiden door een komma. Bijvoorbeeld:

$ ssh-keygen -s ./ca_key
-n user1,user2 -I stor
ge_admins ./id_rsa_user1
pub

Verder kun je een geldigheidsduur instellen met -V (raadpleeg de manpage voor de precieze syntax) en de bekende opties zoals force-command, no-portforwarding et cetera met -O. Op het eerste gezicht vereenvoudigen certificaten het beheer van public keys. Immers, zodra de CA public key op al jouw sshservers is geconfigureerd, hoef je daar niets meer te wijzigen om een nieuwe gebruiker toegang te geven. De problemen komen pas al je een gebruiker de toegang weer wilt afnemen. Er is immers nog geen eenvoudige procedure beschikbaar om een certificaat in te trekken. Met de RevokedKeys-optie in sshd_config kun je wel een bestand aanmaken van public keys die moeten worden geweigerd. Maar dat bestand moet je dus op élke ssh-server aanpassen. Een centrale revocation list, zoals OpenSSL’s CRL-bestanden, zou beter zijn. Je kunt ook certificaten aanmaken voor hosts. Dat is vooral handig om de fingerprint-meldingen te onderdrukken wanneer je voor het eerst inlogt op een server. Ook krijg je dan geen man-in-the-middle-attack waarschuwingen meer als de host key verandert, bijvoorbeeld na een herinstallatie. De identiteit van de remote host is immers gewaarborgd, doordat het certificaat daarvan is ondertekend door de CA. Nog een laatste opmerking: OpenSSH ondersteunt certificaten reeds vanaf versie 5.4, maar in versie 5.6 is het formaat ervan lichtjes gewijzigd. Let dus goed op als je certificaten gebruikt in een omgeving met beide sshversies!