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

Magazine
Marque
GNU/Linux Magazine
Numéro
161
|
Mois de parution
juin 2013
|
Domaines


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/

 

Sur le même sujet

« Certifier » son serveur mail

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

Avoir son propre serveur de mails bien à soi est le rêve de beaucoup d’utilisateurs GNU/Linux. Cependant, depuis quelque temps, les principaux acteurs du net exigent que nous montrions patte blanche avant de transférer ou d'accepter nos courriels. Voyons donc comment faire.

Maîtriser la sécurité de son accès Internet avec OpenWRT

Magazine
Marque
Linux Pratique
Numéro
117
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Nous allons voir dans cet article comment installer le système GNU/Linux embarqué de type OpenWRT. OpenWRT est un système GNU/Linux pour les matériels embarqués et pour les matériels de types routeurs et box. Il constitue donc la part essentielle pour se libérer des GAFA. C’est un système léger, rapide et performant pour administrer et contrôler son accès Internet. Ce système est optimisé pour la gestion des ressources et supporte de nombreux routeurs.

Sondes de détection : performances, évaluations et biais

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En avril 2019, l’ANSSI a qualifié les premières sondes pour assurer la supervision de sécurité de réseaux. Les opérateurs d’importance vitale (OIV), les opérateurs de services essentiels (OSE) et, d’une manière générale, les organismes opérant des fonctions sensibles disposent ainsi de produits français de confiance : Cybels Sensor de Thales et Trackwatch Full Edition de Gatewatcher.La méthodologie d’évaluation des sondes n’est, hélas, pas publique. Les ingénieurs sécurité et réseau devant intégrer ces sondes ne disposent donc pas de guides pour effectuer la recette de leur efficacité en production. Cet article propose un retour d’expérience sur l’évaluation des sondes, notamment sous l’angle de la performance. Cet aspect est, en effet, particulièrement significatif puisque le taux de détection d’une sonde diminue si elle est submergée, quand bien même elle serait équipée des meilleurs signatures et moteurs d’analyse.

WireGuard, le VPN simple et efficace

Magazine
Marque
Linux Pratique
Numéro
116
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Les logiciels de sécurité peuvent être complexes à comprendre et lourds à mettre en œuvre. Cela peut nous freiner dans l’usage et le déploiement d'architectures sécurisées. Mais le logiciel WireGuard veut nous réconcilier avec les solutions de sécurité. Il a pour but de créer un accès VPN performant entre deux machines et ne propose que peu de choix de configuration. En effet, son développeur, Jason A. Donenfeld a pris le parti de n'implémenter qu'un jeu restreint de protocoles cryptographiques, tous à l'état de l'art, et de ne fournir à l'utilisateur qu'une simple interface réseau. Ces choix permettent de masquer beaucoup de la complexité sous-jacente du VPN derrière cette abstraction. Et en plus de cette simplicité de configuration, WireGuard affirme aussi apporter un haut niveau de performance. Je vous propose de vérifier ensemble si cette promesse est bien tenue !

Attaques sur SMB

Magazine
Marque
MISC
HS n°
Numéro
20
|
Mois de parution
octobre 2019
|
Domaines
Résumé

Le service SMB est un point d’entrée privilégié et incontournable sur les systèmes Windows. Easy mode du pentest, en somme. Petit tour d’horizon des vulnérabilités qui l’affectent.

Utilisation des délégations non contraintes pour rebondir entre forêts

Magazine
Marque
MISC
HS n°
Numéro
20
|
Mois de parution
octobre 2019
|
Domaines
Résumé

Depuis plusieurs années, il est admis que la frontière de sécurité d’un Active Directory n’est pas le domaine, mais la forêt, notamment du fait d’attaques telles que l’injection de SIDHistory détaillée dans l’article « La face cachée des relations d’approbation » du MISC n°103. De récentes recherches ont cependant démontré que la forêt ne permettait pas non plus d’assurer une frontière hermétique. Ainsi, il est possible, dans certains cas, de rebondir de forêt en forêt pour compromettre l’ensemble des actifs d’une entreprise.

Par le même auteur

Amazon <3 Linux

Magazine
Marque
GNU/Linux Magazine
Numéro
207
|
Mois de parution
septembre 2017
|
Domaines
Résumé
Qui d'entre vous n'a jamais entendu parler de AWS (Amazon Web Services), LE cloud public qui domine le marché, la panacée du DevOps, le destructeur de toute une industrie, l'hébergeur qui soutient désormais un bon 40% du Web mondial ? Si tu réponds « moi » à cette question, tu devrais visiter autre chose que des sites en HTML v2 et cesser d’éditer tes fichiers de conf à la main.La triple pique d'entrée de jeu c'est gratos, ça me fait plaisir. AWS, c'est le rouleau compresseur, et cette position de leader n'est pas liée à la chance, puisque comme nombre de solutions disruptives, les analystes les plus pointus proféraient à son lancement que « ça marchera jamais » ©®™ ; non, le succès de ce cloud réside en grande partie dans son API, ses outils, le plus souvent libres, et la puissante communauté qui s'est construite autour. Ce que je vous propose dans cet article, c'est de faire connaissance avec ces outils, et en particulier l'AWS cli [1] basée sur boto3[2], tous les deux sous licence Apache 2[3].

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
|
Domaines
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
|
Domaines
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.

Préface

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 différents BSD

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

« Salut, je voudrais installer *BSD, vous me conseillez quoi ? »Cette phrase, lue et relue des centaines, des milliers de fois, est fondamentalement incorrecte. *BSD n'existe pas. Plus important, lorsque l'on souhaite mettre le pied à l'étrier d'un système BSD, un minimum de contexte est nécessaire, car chacun des héritiers de BSD UNIX suit une philosophie bien définie, et si chacun d'entre eux s'avère éminemment versatile, certains seront plus adaptés et faciles d'accès fonction de l'utilisation souhaitée. Nous allons ici faire connaissance avec les trois systèmes BSD les plus connus, NetBSD, FreeBSD et OpenBSD et évoquer leurs forces et faiblesses afin de guider votre choix de façon la plus objective possible.

Demandez la Lune à nginx !

Magazine
Marque
GNU/Linux Magazine
Numéro
172
|
Mois de parution
juin 2014
|
Domaines
Résumé
Nginx n'est plus un logiciel à la marge, avec près de 20% de parts de marché du top un million des sites les plus fréquentés au monde, il représente même un acteur sur lequel on peut (et doit !) compter.