Le logiciel serveur probablement plus installé au monde s'appelle OpenSSH [1], on trouve cette implémentation libre du protocole SSH [2] dans la totalité des UNIX libres et propriétaires, voire la totalité des systèmes d'exploitation. Lorsqu'on administre un parc de plusieurs dizaines, centaines, milliers de machines en utilisant cette suite de logiciels, les méthodes classiques d'authentification peuvent s'avérer fastidieuses, voire dangereuses, nous allons voir dans cet article comment utiliser de façon élégante une nouvelle fonctionnalité du serveur OpenSSH 6.2 qui adresse de façon impeccable cette problématique : AuthorizedKeysCommand.
1. Au début était le fichier texte
Vous n'êtes pas sans ignorer que depuis des temps immémoriaux, LA méthode recommandée pour se connecter à l'aide d'un terminal vers une machine distante consiste à copier une clé publique, pendant de votre clé privée, dans le fichier ~/.ssh/authorized_keys du serveur distant. Cette méthode est pratique et rapide, sous GNU/Linux, on dispose pour réaliser cette opération sans perte de temps de la commande ssh-copy-id, dont on pourra reproduire le fonctionnement depuis n'importe quel shell à l'aide d'un alias. Par exemple :
ssh_copy_id()
{
[ -f ~/.ssh/id_rsa.pub ] && PK=id_rsa || PK=id_dsa
cat ~/.ssh/${PK}.pub | \
ssh $1 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
}
À l'aide de systèmes d'orchestration tels que fabric, ansible, salt, puppet et j'en passe, le déploiement de clé s'avère relativement automatisable et simple. Inutile de poursuivre cet article, me direz-vous ? Halte-là moussaillon, point de chaos sur mes plateformes, quid de l'employé qui fuit, des clés faibles, du contrôle du degré de permission ? Non, les fichiers texte, c'est décidément trop 90's.
2. Puis vint OpenSSH-LPK
Aaah OpenSSH-LPK [3], une belle histoire. OpenSSH-LPK, pour LDAP PubKey, est un patch développé par Éric Augé alors que nous travaillions tous deux dans feu la société ISDnet, un opérateur IP absorbé puis démantelé par la société Cable & Wireless. Ce patch implémentait ce dont nous avions besoin : la possibilité d'interroger un serveur LDAP pour obtenir les clés publiques associées à un utilisateur. Associé aux fameux pam-ldap [4] et nss-ldap [5] (nous y reviendrons), il permettait de ne publier des clés publiques SSH que sur un serveur LDAP, interrogé par tous les serveurs lorsqu'une connexion se présentait.
Pour des raisons obscures, OpenSSH-LPK n'a jamais pu faire son chemin jusqu'à l'upstream, ainsi depuis 2001, le patch se promène de mainteneur en mainteneur, de distribution en distribution, et je profite d'ailleurs de cet article pour féliciter et remercier l'équipe de Gentoo qui a maintenu contre vents et marées ce patch de façon qu'il m'a toujours été possible, d'une manière ou d'une autre, de l'appliquer et le packager.
Bien que ce patch soit toujours en vie, nous allons voir que ses jours sont comptés en raison de l'arrivée d'une nouvelle fonctionnalité, montée jusqu'à l'upstream cette fois : AuthorizedKeysCommand.
3. OH MON DIEU ÇA BRULE
Depuis 2009, sur le bugzilla de Damien Miller (Monsieur OpenSSH, donc), on se lamente de ne pas avoir de mécanisme de distribution de clé publique. Et contre toute attente (oui, oui, je sais), le salut proviendra de la société… RedHat. Une approche plus générique, qui ne se concentre pas sur LDAP en particulier, mais donne à OpenSSH la possibilité d'exécuter une commande tierce pour récupérer un flux suivant le formalisme du fichier authorized_keys. Plus aucune limite n'est alors imaginable, via un bête script shell, perl, python, un code compilé, on peut désormais récupérer une liste de clés publiques, en LDAP bien sûr, mais pourquoi pas en HTTP ou n'importe quel autre système farfelu qui traversera votre esprit malade.
La déclaration de cette fonctionnalité s'effectue évidemment dans le fichier sshd_config et brille par sa simplicité :
AuthorizedKeysCommand /home/authkey/bin/openssh-ldap.pl
AuthorizedKeysCommandUser authkey
Exemple brutal de script « helper » glané sur le Web [6], ici l'auteur appelle simplement l'exécutable ldapsearch et filtre le résultat issu de stdout :
#!/usr/bin/perl
die unless $ARGV[0];
open (LDAP, "/usr/bin/ldapsearch -L -x -b\"dc=foo,dc=com\" '(&(objectClass=posixAccount)(uid=$ARGV[0]))' sshPublicKey |") || die "ldapsearch failed $!\n";
while (<LDAP>) {
next if /^#|^version|^dn\:|^\s*$/;
s/\n//;
s/\: //g;
s/sshPublicKey/\n/;
s/^ //;
print;
}
print "\n";
Pas d'API farfelu, pas de JSON, de XML ou encore de YAML, non, on attend un fichier authorized_keys sur la sortie standard. Point.
Autre exemple, plus élégant et pour cause, fourni par David Gwynne aka dlg@OpenBSD [7] qui lit et interprète un résultat fourni par un serveur « Active Directory » (je me lave les mains après l'écriture de cet article…). Ici, David utilise les modules LDAP de Perl pour interroger son serveur via le protocole approprié. Notez que ce script est parfaitement utilisable pour interroger un serveur OpenLDAP par exemple en modifiant simplement les attributs recherchés :
#!/usr/bin/perl -w
use strict;
use Net::DNS;
use Net::LDAP;
use Net::LDAP::Constant qw(LDAP_SUCCESS LDAP_INVALID_CREDENTIALS);
use Net::LDAP::Util qw(escape_filter_value);
sub ad_bind($$$)
{
my $domain = shift;
my $user = shift;
my $pass = shift;
my $res = Net::DNS::Resolver->new;
my $query;
my $answer;
my $ldap_error;
$query = $res->query("_ldap._tcp." . $domain, 'SRV');
if (!$query) {
die "unable to query SRV records for $domain";
}
my @answers = $query->answer;
foreach $answer (@answers) {
my $ldap = new Net::LDAP($answer->target, timeout => 2);
$ldap_error = $@;
next unless ($ldap);
my $mesg = $ldap->bind(sprintf("%s@%s", $user, uc($domain)),
password => $pass);
return ($ldap) if ($mesg->code == LDAP_SUCCESS);
if ($mesg->code == LDAP_INVALID_CREDENTIALS) {
return (undef, $mesg->error);
}
$ldap_error = $mesg->error;
}
return (undef, $ldap_error);
}
if (scalar @ARGV != 1) {
die "username not specified";
}
my $username = $ARGV[0];
my $ad_filter = sprintf('(&(sAMAccountName=%s)(objectClass=user))',
escape_filter_value($username));
my %d = (
'eait.uq.edu.au' => {
'user' => 'sshkeys',
'pass' => 'hahahahaha',
'base' => 'OU=Accounts,DC=eait,DC=uq,DC=edu,DC=au',
'filter' => $ad_filter
}
);
foreach my $domain (keys %d) {
my $param = $d{$domain};
my ($ds, $err) = ad_bind($domain, $param->{'user'}, $param->{'pass'});
next unless ($ds);
my $mesg = $ds->search(
base => $param->{'base'},
filter => $param->{'filter'},
attrs => [ 'altSecurityIdentities' ]
);
next unless ($mesg->code == LDAP_SUCCESS);
for (my $i = 0; $i > $mesg->count; $i++) {
my $entry = $mesg->entry($i);
my @ids = $entry->get_value('altSecurityIdentities');
foreach my $id (@ids) {
my ($type, $value) = split(/:/, $id, 2);
print "$value\n" if ($type eq 'SSHKey');
}
}
}
Et si vous êtes allergique à LDAP, pourquoi ne pas simplement écrire un simple script shell faisant appel à wget ou curl qui téléchargera et fournira sur la sortie standard un fichier authorized_keys situé sur un serveur HTTP distant ?
Les possibilités sont infinies.
4. Plus fort : l'utilisateur fantôme
AuthorizedKeysCommand est une fonctionnalité excellente, mais elle demande évidemment que l'utilisateur UNIX soit au minimum déclaré dans le fichier /etc/passwd afin que ce dernier soit identifié par un UID et un GID. Game Over ? Que nenni, jeune, nous sommes en 2013, toutes les libc des UNIX dignes de ce nom disposent d'une implémentation modulaire du Name Service Switch (NSS pour les intimes). Ainsi, vous pourrez fournir aux primitives get*ent() toutes les informations nécessaires à travers nss-ldap.
L'utilisation de cette fonctionnalité est relativement aisée, par exemple sur un système Debian GNU/Linux, il faudra installer le paquet libnss-ldapd, puis renseigner le fichier /etc/nsswitch.conf avec ces valeurs :
passwd: files ldap
group: files ldap
shadow: files ldap
Vous indiquez ainsi à NSS de chercher d'abord l'entrée dans les fichiers locaux, puis via son backend LDAP. Il faudra configurer le fichier /etc/ldap/ldap.conf, avec au minimum l'URI vers notre serveur LDAP ainsi que la base de recherche :
uri ldap://foo.com
base dc=foo,dc=com
Il s'agit bien du paquet libnss-ldapd et non pas libnss-ldap qui comporte de fâcheux bugs et autres limitations.
On s'assure que notre machinerie fonctionne correctement à l'aide de la commande getent :
imil@tatooine:~$ getent passwd foobar
foobar:*:2000:1337:Mr FooBar:/home/foobar:
De façon à ce que le répertoire $HOME de l'utilisateur virtuel soit créé automatiquement lors de sa première connexion, on utilisera le module PAM pam_mkhomedir. Dans un environnement Debian GNU/Linux, on effectue ce tour de passe-passe en ajoutant dans le fichier /etc/pam.d/common-session :
session required pam_mkhomedir.so skel=/etc/skel umask=0022
Nous pourrons également permettre à notre utilisateur de gérer son mot de passe UNIX, différent de sa passphrase OpenSSH, à nouveau grâce à l'infrastructure PAM, cette fois via l'utilisation de pam-ldap. Sans surprise, le paquet nécessaire se nomme libpam-ldapd. Ce dernier se configure de cette façon :
$ grep ldap /etc/pam.d/common-account
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
$ grep ldap /etc/pam.d/common-auth
auth sufficient pam_ldap.so use_first_pass
$ grep ldap /etc/pam.d/common-password
password sufficient pam_ldap.so
$ grep ldap /etc/pam.d/common-session
session optional pam_ldap.so
Voici, à titre d'exemple, une entrée typique d'utilisateur virtuel délivré par un serveur LDAP :
$ ldapsearch -LLL -x uid=imil
dn: uid=imil,ou=users,dc=foo,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: ldapPublicKey
description: iMil account
cn: iMil
sn: iMil
uid: imil
homeDirectory: /home/imil
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA
wpLAkdp2WloGSh72QGJyRPhe1lGiVKU9/We9lqayoEWs1odq+J
VRcmOl0PuqZ2G7cS3RZf0mOv9Za9KxDhng1dOBjJUJikDfPnDL
UO3BEJrkFZBRTaUQlkajsdf9809sfalkjk8790asdfjkljP5xc
jxiU+iWfA2WCDy5gTClhe7njfQaTOXmPb4eApRhMP1rcQ+Ntzr
OS3gVSQNPhL7bVy61fXBkr8a6s7d6f8kjhlkjdhlakjsdhfj5s
H/5eGr8pw7CEOLCyfSD1ZQs999dsakjdfjashdfklhkjll61QG
cxt5FbXdJHkhSR8gM3QX/EOZXggRK3q7k mBdqnw== imil@ossus
gidNumber: 1000
uidNumber: 1000
loginShell: /bin/bash
Bien loin de l'expérimentation, cette configuration est en place pour un millier de machines virtuelles de type UNIX dans la société pour laquelle je travaille.
5. Le bonheur est dans le paquet
À l'heure où j'écris ces lignes, les paquets officiels Debian ne proposent, et encore, en expérimental, que la version 6.1p1 d'OpenSSH, aussi me suis-je fendu d'un petit guide [8] qui vous permettra de réaliser vos propres paquets d'OpenSSH 6.2 et bénéficier ainsi de la puissance de l'AuthorizedKeysCommand. Bien évidemment, OpenBSD est agrémenté dans sa toute nouvelle release 5.3 d'un OpenSSH à jour, et comme je n'ai pu m'en empêcher, vous trouverez OpenSSH 6.2 dans pkgsrc/security/openssh, probablement disponible sous forme de binaire lorsque vous tiendrez ce magazine entre vos mains.
Références
[2] http://fr.wikipedia.org/wiki/Secure_Shell
[3] https://code.google.com/p/openssh-lpk/
[4] http://www.padl.com/OSS/pam_ldap.html
[5] http://www.padl.com/OSS/nss_ldap.html
[6] http://blather.michaelwlucas.com/archives/1562
[7] http://www.sysadmin.org.au/index.php/2012/12/authorizedkeyscommand/
[8] http://imil.net/wp/2013/04/29/debian-backport-of-openssh-6-2/
