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

Game & Watch : utilisons judicieusement la mémoire

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

Au terme de l'article précédent [1] concernant la transformation de la console Nintendo Game & Watch en plateforme de développement, nous nous sommes heurtés à un problème : les 128 Ko de flash intégrés au microcontrôleur STM32 sont une ressource précieuse, car en quantité réduite. Mais heureusement pour nous, le STM32H7B0 dispose d'une mémoire vive de taille conséquente (~ 1,2 Mo) et se trouve être connecté à une flash externe QSPI offrant autant d'espace. Pour pouvoir développer des codes plus étoffés, nous devons apprendre à utiliser ces deux ressources.

Raspberry Pi Pico : PIO, DMA et mémoire flash

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

Le microcontrôleur RP2040 équipant la Pico est une petite merveille et malgré l'absence de connectivité wifi ou Bluetooth, l'étendue des fonctionnalités intégrées reste très impressionnante. Nous avons abordé le sujet du sous-système PIO dans un précédent article [1], mais celui-ci n'était qu'une découverte de la fonctionnalité. Il est temps à présent de pousser plus loin nos expérimentations en mêlant plusieurs ressources à notre disposition : PIO, DMA et accès à la flash QSPI.

Programmation des PIO de la Raspberry Pi Pico

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

La carte Pico de Raspberry Pi est appréciable à bien des égards. Ses ressources, son prix, ses deux cœurs ARM... Mais ce morceau de silicium qu'est le RP2040 renferme une fonctionnalité unique : des blocs PIO permettant de créer librement des périphériques supplémentaires qu'il s'agisse d'éléments standardisés comme SPI, UART ou i2c, ou des choses totalement exotiques et très spécifiques à un projet ou un environnement donné. Voyons ensemble comment prendre en main cette ressource et explorer le monde fantastique des huit machines à états de la Pico !

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