AuthorizedKeysCommand : quand OpenSSH devient CloudSSH. Nan j'déconne.

Magazine
Marque
GNU/Linux Magazine
Numéro
161
Mois de parution
juin 2013
Spécialité(s)


Résumé

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.


Body

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

[1] http://www.openssh.com/

[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/

 



Article rédigé par

Par le(s) même(s) auteur(s)

Des bits comme s'il en pleuvait : une appliance SAN/NAS sous NetBSD

Magazine
Marque
GNU/Linux Magazine
Numéro
181
Mois de parution
avril 2015
Spécialité(s)
Résumé
À Noël, je suis le désespoir de ma famille. En effet, là où d'autres demandent des Blu-ray, de quoi s'habiller en hiver ou encore une nouvelle poêle à frire, moi je demande des composants. Des disques, des cartes, des trucs super pas excitants pour les personnes qui vous les offrent. Cette année, je voulais plus de place sur mon NAS [1], plein de bits pour y coller des documents à haute teneur multimédia.

NetBSD, le système du futur du subjonctif

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
Mois de parution
septembre 2014
Spécialité(s)
Résumé
« The Original UNIX », c'est pour cette punchline que j'avais voté lorsque le groupe chargé du marketing chez NetBSD cherchait une approche différente du classique « of course it runs NetBSD » ; néanmoins, s'il est l'héritier le plus direct des travaux du CSRG [1] et l'un des plus grands défenseurs de la portabilité du code, le projet NetBSD n'est certainement pas un système d'exploitation du passé, loin s'en faut. Bénéficiant des avancées standards d'autres OS, NetBSD dispose en outre d'avantages uniques dont l'administrateur système aguerri saura faire usage. Dans cet article, nous allons monter un serveur web articulé autour de briques modernes, et allons dans notre périple découvrir l'ensemble des éléments nécessaires au déploiement d'un système aussi réactif que respectueux des standards.

Systèmes BSD : la préface du guide pour les installer et bien les administrer

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
Mois de parution
septembre 2014
Résumé

Huit ans. Huit ans se sont écoulés depuis les deux derniers numéros hors-séries BSD et le mook que vous tenez entre les mains. Il y a huit ans, il est probable qu'une bonne partie d'entre vous n'avait même jamais touché un système UNIX/Linux, et réalisait plutôt son grand œuvre Lego(c)(tm).

Pendant ces huit années, le monde du Libre a proprement explosé, il est partout, omniprésent sur vos mobiles, vos tablettes, votre télé ou votre point d'accès Wi-Fi ; et si des sociétés telles que Google ne se cachent pas d'utiliser le système GNU/Linux comme socle entre l'espace utilisateur et le matériel, d'autres, sans totalement le masquer, ne font pas étalage des technologies libres constituant la pierre angulaire de leurs systèmes. En tête de liste notons particulièrement la société Apple, dont l'espace utilisateur du système d'exploitation Mac OS X est directement issu de FreeBSD.

Les derniers articles Premiums

Les derniers articles Premium

Stubby : protection de votre vie privée via le chiffrement des requêtes DNS

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Depuis les révélations d’Edward Snowden sur l’espionnage de masse des communications sur Internet par la NSA, un effort massif a été fait pour protéger la vie en ligne des internautes. Cet effort s’est principalement concentré sur les outils de communication avec la généralisation de l’usage du chiffrement sur le web (désormais, plus de 90 % des échanges se font en HTTPS) et l’adoption en masse des messageries utilisant des protocoles de chiffrement de bout en bout. Cependant, toutes ces communications, bien que chiffrées, utilisent un protocole qui, lui, n’est pas chiffré par défaut, loin de là : le DNS. Voyons ensemble quels sont les risques que cela induit pour les internautes et comment nous pouvons améliorer la situation.

Surveillez la consommation énergétique de votre code

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Être en mesure de surveiller la consommation énergétique de nos applications est une idée attrayante, qui n'est que trop souvent mise à la marge aujourd'hui. C'est d'ailleurs paradoxal, quand on pense que de plus en plus de voitures permettent de connaître la consommation instantanée et la consommation moyenne du véhicule, mais que nos chers ordinateurs, fleurons de la technologie, ne le permettent pas pour nos applications... Mais c'est aussi une tendance qui s'affirme petit à petit et à laquelle à terme, il devrait être difficile d'échapper. Car même si ce n'est qu'un effet de bord, elle nous amène à créer des programmes plus efficaces, qui sont également moins chers à exécuter.

Donnez une autre dimension à vos logs avec Vector

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Avoir des informations précises et détaillées sur ce qu’il se passe dans une infrastructure, et sur les applications qu'elle héberge est un enjeu critique pour votre business. Cependant, ça demande du temps, temps qu'on préfère parfois se réserver pour d'autres tâches jugées plus prioritaires. Mais qu'un système plante, qu'une application perde les pédales ou qu'une faille de sécurité soit découverte et c'est la panique à bord ! Alors je vous le demande, qui voudrait rester aveugle quand l'observabilité a tout à vous offrir ?

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 49 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous