Comment configurer l'authentification à plusieurs facteurs pour SSH sur Ubuntu 16.04

Vous n'utilisez pas Ubuntu 16.04 ? Choisissez une version ou une distribution différente.

Introduction

Un facteur d'authentification est une seule information utilisée pour prouver que vous avez le droit d'effectuer une action, comme se connecter à un système. Un canal d'authentification est la manière dont un système d'authentification livre un facteur à l'utilisateur ou exige que l'utilisateur réponde. Les mots de passe et les jetons de sécurité sont des exemples de facteurs d'authentification ; les ordinateurs et les téléphones sont des exemples de canaux.

SSH utilise par défaut des mots de passe pour l'authentification, et la plupart des instructions de durcissement SSH recommandent d'utiliser une clé SSH à la place. Cependant, cela reste un seul facteur. Si un acteur malveillant a compromis votre ordinateur, alors il peut utiliser votre clé pour compromettre vos serveurs également.

Dans ce tutoriel, nous allons mettre en place une authentification à plusieurs facteurs pour lutter contre cela. L'authentification à plusieurs facteurs (MFA) nécessite plus d'un facteur pour authentifier ou se connecter. Cela signifie qu'un acteur malveillant devrait compromettre plusieurs éléments, comme votre ordinateur et votre téléphone, pour entrer. Les différents types de facteurs sont souvent résumés comme suit :

1. Quelque chose que vous savez, comme un mot de passe ou une question de sécurité
2. Quelque chose que vous avez, comme une application d'authentification ou un jeton de sécurité
3. Quelque chose que vous êtes, comme votre empreinte digitale ou votre voix.

Un facteur commun est une application OATH-TOTP, comme Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) est un protocole ouvert qui génère un mot de passe à usage unique, généralement un numéro à 6 chiffres qui est régénéré toutes les 30 secondes.

Cet article expliquera comment activer l'authentification SSH en utilisant une application OATH-TOTP en plus d'une clé SSH. Se connecter à votre serveur via SSH nécessitera alors deux facteurs sur deux canaux, rendant ainsi le processus plus sécurisé qu'un mot de passe ou une clé SSH seule. De plus, nous aborderons quelques cas d'utilisation supplémentaires pour l'authentification multifacteur (MFA) et quelques conseils et astuces utiles.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de :

• Un serveur Ubuntu 16.04 avec un utilisateur non-root ayant des droits sudo, une clé SSH et un pare-feu activé, que vous pouvez configurer en suivant ce tutoriel de configuration initiale du serveur.
• Un smartphone ou une tablette avec une application OATH-TOTP installée, comme Google Authenticator (iOS, Android).

Étape 1 — Installer le PAM de Google

Dans cette étape, nous allons installer et configurer le PAM de Google.

PAM, qui signifie Module d'Authentification Pluggable, est une infrastructure d'authentification utilisée sur les systèmes Linux pour authentifier un utilisateur. Parce que Google a créé une application OATH-TOTP, ils ont également créé un PAM qui génère des TOTPs et est entièrement compatible avec n'importe quelle application OATH-TOTP, comme Google Authenticator ou Authy.

Tout d'abord, mettez à jour le cache du dépôt d'Ubuntu.

sudo apt-get update

Ensuite, installez le PAM.

sudo apt-get install libpam-google-authenticator

Avec le PAM installé, nous utiliserons une application d'aide fournie avec le PAM pour générer une clé TOTP pour l'utilisateur auquel vous souhaitez ajouter un second facteur. Cette clé est générée pour chaque utilisateur, pas à l'échelle du système. Cela signifie que chaque utilisateur qui souhaite utiliser une application d'authentification TOTP devra se connecter et exécuter l'application d'aide pour obtenir sa propre clé ; vous ne pouvez pas simplement l'exécuter une fois pour l'activer pour tout le monde (mais il y a quelques conseils à la fin de ce tutoriel pour configurer ou exiger une MFA pour de nombreux utilisateurs).

Exécutez l'application d'initialisation.

google-authenticator

Après avoir exécuté la commande, vous aurez à répondre à quelques questions. La première demande si les jetons d'authentification doivent être basés sur le temps.

Do you want authentication tokens to be time-based (y/n) y

Ce PAM permet d'utiliser des jetons basés sur le temps ou des jetons basés sur une séquence. Utiliser des jetons basés sur une séquence signifie que le code commence à un certain point et s'incrémente après chaque utilisation. Utiliser des jetons basés sur le temps signifie que le code change de manière aléatoire après qu'un certain temps s'est écoulé. Nous allons nous en tenir aux jetons basés sur le temps car c'est ce que les applications comme Google Authenticator anticipent, donc répondez y pour oui.

Après avoir répondu à cette question, beaucoup de contenu défileront, y compris un grand code QR. À ce stade, utilisez votre application d'authentification sur votre téléphone pour scanner le code QR ou tapez manuellement la clé secrète. Si le code QR est trop grand pour être scanné, vous pouvez utiliser l'URL au-dessus du code QR pour obtenir une version plus petite. Une fois ajouté, vous verrez un code à six chiffres qui change toutes les 30 secondes dans votre application.

Les questions restantes informent le PAM sur son fonctionnement. Nous les examinerons une par une.

Do you want me to update your "~/.google_authenticator" file (y/n) y

Ceci écrit la clé et les options dans le fichier .google_authenticator. Si vous dites non, le programme quitte et rien n'est écrit, ce qui signifie que l'authentificateur ne fonctionnera pas.

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

En répondant oui ici, vous empêchez une attaque par rejeu en faisant expirer chaque code immédiatement après son utilisation. Cela empêche un attaquant de capturer un code que vous venez d'utiliser et de s'identifier avec.

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n

Répondre oui ici permet jusqu'à 8 codes valides dans une fenêtre de quatre minutes mobile. En répondant non, vous limitez cela à 3 codes valides dans une fenêtre mobile de 1:30 minute. À moins que vous ne trouviez des problèmes avec la fenêtre de 1:30 minute, répondre non est le choix le plus sécurisé.

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

La limitation de débit signifie qu'un attaquant distant ne peut tenter qu'un certain nombre de tentatives avant d'être bloqué. Si vous n'avez pas précédemment configuré la limitation de débit directement dans SSH, le faire maintenant est une excellente technique de durcissement.

Maintenant que le PAM de Google est installé et configuré, la prochaine étape consiste à configurer SSH pour utiliser votre clé TOTP. Nous devrons informer SSH au sujet du PAM, puis configurer SSH pour l'utiliser.

Étape 2 — Configuration d'OpenSSH

Parce que nous allons effectuer des modifications SSH via SSH, il est important de ne jamais fermer votre connexion SSH initiale. Au lieu de cela, ouvrez une deuxième session SSH pour effectuer des tests. Cela permet d'éviter de vous verrouiller hors de votre serveur s'il y avait une erreur dans votre configuration SSH. Une fois que tout fonctionne, vous pouvez alors fermer en toute sécurité toutes les sessions.

Pour commencer, ouvrez le fichier de configuration sshd pour édition en utilisant nano ou votre éditeur de texte préféré.

sudo nano /etc/pam.d/sshd

Ajoutez la ligne suivante en bas du fichier.

. . .
Standard Un*x password updating.
@include common-password
auth required pam_google_authenticator.so nullok

Le mot nullok à la fin de la dernière ligne indique à PAM que cette méthode d'authentification est facultative. Cela permet aux utilisateurs sans un jeton OATH-TOTP de se connecter en utilisant leur clé SSH. Une fois que tous les utilisateurs ont un jeton OATH-TOTP, vous pouvez retirer nullok de cette ligne pour rendre la MFA obligatoire.

Enregistrez et fermez le fichier.

Ensuite, nous allons configurer SSH pour prendre en charge ce type d'authentification. Ouvrez le fichier de configuration SSH pour modification.

sudo nano /etc/ssh/sshd_config

Recherchez ChallengeResponseAuthentication et définissez sa valeur sur yes.

. . .
Change to yes to enable challenge-response passwords (beware issues with
some PAM modules and threads)
ChallengeResponseAuthentication yes
. . .

Enregistrez et fermez le fichier, puis redémarrez SSH pour recharger les fichiers de configuration. Le redémarrage du service sshd ne fermera pas les connexions ouvertes, donc vous ne risquez pas de vous verrouiller dehors avec cette commande.

sudo systemctl restart sshd.service

Pour tester que tout fonctionne jusqu'à présent, ouvrez un autre terminal et essayez de vous connecter via SSH. Si vous avez précédemment créé une clé SSH et que vous l'utilisez, vous remarquerez que vous n'avez pas eu à saisir le mot de passe de votre utilisateur ni le code de vérification MFA. Cela est dû au fait qu'une clé SSH remplace par défaut toutes les autres options d'authentification. Sinon, vous auriez reçu une invite pour le mot de passe et le code de vérification.

Ensuite, pour activer une clé SSH comme un facteur et le code de vérification comme un second, nous devons indiquer à SSH quels facteurs utiliser et empêcher la clé SSH de remplacer tous les autres types.

Étape 3 — Rendre SSH conscient de l'authentification multifacteur (MFA)

Rouvrez le fichier de configuration sshd.

sudo nano /etc/ssh/sshd_config

Ajoutez la ligne suivante à la fin du fichier. Cela indique à SSH quels sont les modes d'authentification requis. Cette ligne indique à SSH que nous avons besoin d'une clé SSH et soit d'un mot de passe, soit d'un code de vérification (ou des trois).

. . .
UsePAM yes
AuthenticationMethods publickey,password publickey,keyboard-interactive

Enregistrez et fermez le fichier.

Ensuite, ouvrez à nouveau le fichier de configuration sshd de PAM.

sudo nano /etc/pam.d/sshd

Trouvez la ligne @include common-auth et commentez-la en ajoutant un caractère # comme premier caractère de la ligne. Cela indique à PAM de ne pas demander de mot de passe.

. . .
Standard Un*x authentication.
#@include common-auth
. . .

Enregistrez et fermez le fichier, puis redémarrez SSH.

sudo systemctl restart sshd.service

Essayez maintenant de vous connecter au serveur à nouveau avec une session différente. Contrairement à la dernière fois, SSH devrait demander votre code de vérification. En l'entrant, vous serez connecté. Même si vous ne voyez aucune indication que votre clé SSH a été utilisée, votre tentative de connexion a utilisé deux facteurs. Si vous souhaitez vérifier, vous pouvez ajouter -v (pour verbose) après la commande SSH :

Example SSH output\
. . .
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammy/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
Authenticated with partial success.
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Verification code:

Vers la fin de la sortie, vous verrez où SSH utilise votre clé SSH et demande ensuite le code de vérification. Vous pouvez maintenant vous connecter via SSH avec une clé SSH et un mot de passe à usage unique. Si vous souhaitez appliquer les trois types d'authentification, vous pouvez suivre l'étape suivante.

Étape 4 — Ajouter un troisième facteur (facultatif)

Dans l'étape 3, nous avons énuméré les types d'authentification approuvés dans le fichier sshd_config :

1. clépublique (clé SSH)
2. mot de passe clé publique (mot de passe)
3. clavier-interactif (code de vérification)

Bien que nous ayons énuméré trois facteurs différents, avec les options que nous avons choisies jusqu'à présent, elles ne permettent qu'une clé SSH et le code de vérification. Si vous souhaitez avoir les trois facteurs (clé SSH, mot de passe et code de vérification), un rapide changement activera les trois.

Ouvrez le fichier de configuration sshd de PAM.

sudo nano /etc/pam.d/sshd

Repérez la ligne que vous avez commentée précédemment, #@include common-auth, et décommentez la ligne en supprimant le caractère #. Enregistrez et fermez le fichier. Maintenant, redémarrez à nouveau SSH.

sudo systemctl restart sshd.service

En activant l'option @include common-auth, PAM demandera désormais un mot de passe en plus de la vérification d'une clé SSH et de la demande d'un code de vérification, ce qui fonctionnait auparavant. Nous pouvons maintenant utiliser quelque chose que nous savons (le mot de passe) et deux types différents de choses que nous avons (la clé SSH et le code de vérification) sur deux canaux différents.

Jusqu'à présent, cet article a décrit comment activer l'authentification multi-facteurs (MFA) avec une clé SSH et un mot de passe à usage unique basé sur le temps. Si c'est tout ce dont vous avez besoin, vous pouvez en rester là. Cependant, ce n'est pas la seule façon de réaliser une authentification multi-facteurs. Voici quelques méthodes supplémentaires pour utiliser ce module PAM pour l'authentification multi-facteurs et quelques conseils et astuces pour la récupération, l'utilisation automatisée, et plus encore.

Astuce 1 — Récupération d'accès

Comme avec tout système que vous durcissez et sécurisez, vous devenez responsable de la gestion de cette sécurité. Dans ce cas, cela signifie ne pas perdre votre clé SSH ou votre clé secrète TOTP et vous assurer que vous avez accès à votre application TOTP. Cependant, parfois, des choses se passent et vous pouvez perdre le contrôle des clés ou des applications dont vous avez besoin pour entrer.

Perdre une clé SSH ou une clé secrète TOTP

Si vous perdez votre clé SSH ou votre clé secrète TOTP, la récupération peut être divisée en plusieurs étapes. La première consiste à revenir sans connaître le code de vérification et la seconde à trouver la clé secrète ou à la régénérer pour une connexion MFA normale.

Pour accéder à votre Droplet DigitalOcean après avoir perdu la clé secrète qui génère le code de vérification, vous pouvez simplement utiliser la console virtuelle depuis votre tableau de bord pour vous connecter avec votre nom d'utilisateur et votre mot de passe.

Sinon, vous aurez besoin d'un utilisateur administratif ayant un accès sudo ; assurez-vous de ne pas activer l'authentification à deux facteurs pour cet utilisateur, mais utilisez une clé SSH. Si vous ou un autre utilisateur perdez leur clé secrète et ne pouvez pas vous connecter, l'utilisateur administratif peut se connecter et aider à récupérer ou régénérer la clé pour tout utilisateur en utilisant sudo.

Une fois que vous êtes connecté, il y a deux façons d'obtenir le secret TOTP :

1. Récupérer la clé existante
2. Générer une nouvelle clé

Dans le répertoire personnel de chaque utilisateur, la clé secrète et les paramètres de Google Authenticator sont enregistrés dans ~/.google-authenticator. La toute première ligne de ce fichier est une clé secrète. Un moyen rapide d'obtenir la clé est d'exécuter la commande suivante, qui affiche la première ligne du fichier google-authenticator (c'est-à-dire la clé secrète). Ensuite, prenez cette clé secrète et tapez-la manuellement dans une application TOTP.

head -n 1 /home/sammy/.google_authenticator

S'il y a une raison de ne pas utiliser la clé existante (par exemple, être incapable de partager facilement la clé secrète en toute sécurité avec l'utilisateur concernés), vous pouvez supprimer le fichier ~/.google-authenticator complètement. Cela permettra à l'utilisateur de se connecter à nouveau en utilisant uniquement un seul facteur, en supposant que vous n'avez pas imposé la MFA. Il peut alors exécuter google-authenticator pour générer une nouvelle clé.

Perte d'accès à l'application TOTP

Si vous devez vous connecter à votre serveur mais n'avez pas accès à votre application TOTP pour obtenir votre code de vérification, vous pouvez toujours vous connecter en utilisant les codes de récupération qui ont été affichés lorsque vous avez créé pour la première fois votre clé secrète. Notez que ces codes de récupération ne peuvent être utilisés qu'une seule fois. Une fois qu'un code a été utilisé pour se connecter, il ne peut plus être utilisé comme code de vérification.

Astuce 2 — Changer les paramètres d'authentification

Si vous souhaitez modifier vos paramètres MFA après la configuration initiale, au lieu de générer une nouvelle configuration avec les paramètres mis à jour, vous pouvez simplement modifier le fichier ~/.google-authenticator. Ce fichier est structuré de la manière suivante :

<secret key>
<options>
<recovery codes>

Les options qui sont définies dans ce fichier ont une ligne dans la section des options ; si vous avez répondu « non » à une option particulière lors de la configuration initiale, la ligne correspondante est exclue du fichier.

Voici les modifications que vous pouvez apporter à ce fichier :

• Pour activer les codes séquentiels au lieu des codes basés sur le temps, modifiez la ligne " TOTP_AUTH en " HOTP_COUNTER 1.
• Pour permettre plusieurs utilisations d'un seul code, supprimez la ligne " DISALLOW_REUSE.
• Pour étendre la fenêtre d'expiration du code à 4 minutes, ajoutez la ligne " WINDOW_SIZE 17.
• Pour désactiver plusieurs échecs de connexion (limitation du taux), supprimez la ligne " RATE_LIMIT 3 30.
• Pour changer le seuil de limitation de taux, trouvez la ligne " RATE_LIMIT 3 30 et ajustez les chiffres. Le 3 dans l'original indique le nombre de tentatives sur une période de temps, et le 30 indique la période de temps en secondes.
• Pour désactiver l'utilisation des codes de récupération, supprimez les cinq codes à 8 chiffres au bas du fichier.

Conseil 3 — Éviter l'authentification multi-facteurs pour certains comptes

Il peut y avoir une situation dans laquelle un utilisateur unique ou quelques comptes de service (c'est-à-dire des comptes utilisés par des applications, pas des humains) ont besoin d'un accès SSH sans MFA activé. Par exemple, certaines applications qui utilisent SSH, comme certains clients FTP, peuvent ne pas prendre en charge la MFA. Si une application n'a pas de moyen de demander le code de vérification, la demande peut rester bloquée jusqu'à ce que la connexion SSH expire.

Tant que quelques options dans /etc/pam.d/sshd sont correctement définies, vous pouvez contrôler quels facteurs sont utilisés sur une base utilisateur par utilisateur.

Pour permettre l'authentification à plusieurs facteurs (MFA) pour certains comptes et l'authentification SSH uniquement pour d'autres, assurez-vous que les paramètres suivants dans /etc/pam.d/sshd sont actifs.

PAM configuration for the Secure Shell service

Standard Un*x authentication.
#@include common-auth

. . .

Standard Un*x password updating.
@include common-password
auth required pam_google_authenticator.so nullok

Ici, @include common-auth est commenté car les mots de passe doivent être désactivés. L'authentification multi-facteurs ne peut pas être forcée si certains comptes doivent avoir l'authentification multi-facteurs désactivée, donc laissez l'option nullok sur la dernière ligne.

Après avoir configuré cela, exécutez simplement google-authenticator pour tous les utilisateurs qui ont besoin de MFA, et ne l'exécutez pas pour les utilisateurs qui n'utiliseront que des clés SSH.

Conseil 4 — Automatiser la configuration avec la gestion de configuration

De nombreux administrateurs système utilisent des outils de gestion de configuration, comme Puppet, Chef ou Ansible, pour gérer leurs systèmes. Si vous souhaitez utiliser un système comme celui-ci pour installer une clé secrète lors de la création d'un compte utilisateur, il existe une méthode pour le faire.

google-authenticator prend en charge des commutateurs en ligne de commande pour définir toutes les options en une seule commande non interactive. Pour voir toutes les options, vous pouvez taper google-authenticator --help. Voici la commande qui configurerait tout comme décrit à l'Étape 1 :

google-authenticator -t -d -f -r 3 -R 30 -W

Cela répond à toutes les questions que nous avons répondu manuellement, les enregistre dans un fichier, puis affiche la clé secrète, le code QR et les codes de récupération. (Si vous ajoutez le drapeau -q, il n'y aura pas de sortie.) Si vous utilisez cette commande de manière automatisée, assurez-vous de capturer la clé secrète et/ou les codes de récupération et de les rendre disponibles à l'utilisateur.

Conseil 5 — Forcer l'authentification multi-facteurs pour tous les utilisateurs

Si vous souhaitez forcer l'authentification à multiples facteurs (MFA) pour tous les utilisateurs, même lors de la première connexion, ou si vous préférez ne pas dépendre de vos utilisateurs pour générer leurs propres clés, il existe un moyen simple de gérer cela. Vous pouvez simplement utiliser le même fichier .google-authenticator pour chaque utilisateur, car il n'y a pas de données spécifiques à l'utilisateur stockées dans le fichier.

Pour ce faire, après que le fichier de configuration a été initialement créé, un utilisateur privilégié doit copier le fichier dans le répertoire racine de chaque répertoire personnel et changer ses permissions pour l'utilisateur approprié. Vous pouvez également copier le fichier dans /etc/skel afin qu'il soit automatiquement copié dans le répertoire personnel d'un nouvel utilisateur lors de sa création.

Une autre méthode pour forcer la création de la clé secrète d'un utilisateur consiste à utiliser un script bash qui :

1. Crée un token TOTP,
2. Les invite à télécharger l'application Google Authenticator et à scanner le code QR qui sera affiché, et
3. Exécute l'application google-authenticator pour eux après avoir vérifié si le fichier .google-authenticator existe déjà.

Pour s'assurer que le script s'exécute lorsqu'un utilisateur se connecte, vous pouvez l'appeler .bash_login et le placer à la racine de son répertoire personnel.

Conclusion

Cela dit, en ayant deux facteurs (une clé SSH + un jeton MFA) sur deux canaux (votre ordinateur + votre téléphone), vous avez rendu très difficile pour un agent extérieur de forcer l'accès à votre machine via SSH et avez considérablement augmenté la sécurité de votre machine.