Comment configurer l’authentification multifactorielle pour SSH sur CentOS 7

Introduction

Un facteur d’authentification est un élément d’information unique utilisé pour prouver que vous avez les droits d’effectuer une action, comme la connexion à un système. Un canal d’authentification est la manière dont un système d’authentification délivre un facteur à l’utilisateur ou demande à l’utilisateur de répondre. 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 de SSH recommandent d’utiliser plutôt une clé SSH. Cependant, il ne s’agit toujours que d’un seul facteur. Si un mauvais acteur a compromis votre ordinateur, alors il peut utiliser votre clé pour compromettre également vos serveurs.

Dans ce tutoriel, nous allons configurer l’authentification multifactorielle pour combattre cela. L’authentification multifactorielle (MFA) nécessite plus d’un facteur afin de s’authentifier, ou de se connecter. Cela signifie qu’un mauvais acteur doit compromettre plusieurs éléments, comme votre ordinateur et votre téléphone, pour pouvoir se connecter. Les différents types de facteurs sont souvent résumés comme suit :

1. Quelque chose que vous connaissez, comme un mot de passe ou une question de sécurité
2. Quelque chose que vous avez, comme une appli 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 appli 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, communément un nombre à 6 chiffres qui est recyclé toutes les 30 secondes.

Cet article passera en revue comment activer l’authentification SSH en utilisant une app OATH-TOTP en plus d’une clé SSH. La connexion à votre serveur via SSH nécessitera alors deux facteurs sur deux canaux, ce qui la rendra plus sûre qu’un mot de passe ou une clé SSH seuls. En outre, nous passerons en revue quelques cas d’utilisation supplémentaires pour MFA et quelques conseils et astuces utiles.

Prérequis

Pour suivre ce tutoriel, vous aurez besoin :

• D’un serveur CentOS 7 avec un utilisateur sudo non-root et une clé SSH, que vous pouvez configurer en suivant ce tutoriel Configuration initiale du serveur.
• Un smartphone ou une tablette avec une application OATH-TOTP installée, comme Google Authenticator (iOS, Android).

Etape 1 – Installation du PAM de Google

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

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

D’abord, nous devons ajouter le repo EPEL (Extra Packages for Enterprise Linux).

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Puis, installer le PAM. Vous pouvez être invité à accepter la clé EPEL si c’est la première fois que vous utilisez le repo. Une fois acceptée, vous ne serez plus invité à accepter la clé.

sudo yum install 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 voulez ajouter un second facteur. Cette clé est générée sur une base utilisateur par utilisateur, et non pas à l’échelle du système. Cela signifie que chaque utilisateur qui veut utiliser une app d’authentification TOTP devra se connecter et exécuter l’app d’aide pour obtenir sa propre clé ; vous ne pouvez pas l’exécuter une seule fois pour l’activer pour tout le monde (mais il y a quelques conseils à la fin de ce tutoriel pour configurer ou exiger MFA pour de nombreux utilisateurs).

Exécuter l’app d’initialisation.

google-authenticator

Après avoir exécuté la commande, quelques questions vous seront posées. La première demande si les jetons d’authentification doivent être basés sur le temps.

Output
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 séquentiels. Utiliser des jetons basés sur la séquence signifie que le code commence à un certain point et incrémente ensuite le code après chaque utilisation. L’utilisation de jetons basés sur le temps signifie que le code change de façon aléatoire après un certain temps. Nous nous en tiendrons à l’utilisation de jetons basés sur le temps parce que c’est ce que des applications comme Google Authenticator prévoient, alors répondez y pour oui.

Après avoir répondu à cette question, beaucoup de résultats 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 qu’il est ajouté, vous verrez un code à six chiffres qui change toutes les 30 secondes dans votre application.

Note : Assurez-vous d’enregistrer la clé secrète, le code de vérification et les codes de récupération dans un endroit sûr, comme un gestionnaire de mots de passe. Les codes de récupération sont le seul moyen de retrouver l’accès si tu perds, par exemple, l’accès à ton appli TOTP.

Les questions restantes informent le PAM de son fonctionnement. Nous allons les passer en revue une par une.

Output
Do you want me to update your "/home/sammy/.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.

Output
Do you want to disallow multiple uses of the same authenticationtoken? This restricts you to one login about every 30s, but it increasesyour 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 se connecter avec lui.

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n

En répondant oui ici, vous autorisez jusqu’à 8 codes valides dans une fenêtre mobile de quatre minutes. En répondant non, vous le limitez à 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ûr.

Output
If the computer that you are logging into isn't hardened against brute-forcelogin 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 du taux signifie qu’un attaquant distant ne peut tenter qu’un certain nombre de suppositions avant d’être bloqué. Si vous n’avez pas précédemment configuré la limitation de taux directement dans SSH, le faire maintenant est une excellente technique de durcissement.

Note : Une fois que vous avez terminé cette configuration, si vous voulez sauvegarder votre clé secrète, vous pouvez copier le fichier ~/.google-authenticator dans un emplacement de confiance. De là, vous pouvez le déployer sur des systèmes supplémentaires ou le redéployer après une sauvegarde.

Maintenant que PAM de Google est installé et configuré, l’étape suivante consiste à configurer SSH pour utiliser votre clé TOTP. Nous devrons indiquer à SSH le PAM et ensuite configurer SSH pour l’utiliser.

Étape 2 – Configuration d’OpenSSH

Parce que nous allons effectuer des modifications SSH sur 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. Ceci afin d’éviter de vous bloquer hors de votre serveur en cas d’erreur dans votre configuration SSH. Une fois que tout fonctionne, alors vous pouvez fermer toutes les sessions en toute sécurité.

Pour commencer, nous allons modifier le fichier de configuration sshd. Ici, nous utilisons nano, qui n’est pas installé par défaut sur CentOS. Vous pouvez l’installer avec sudo yum install nano, ou utiliser votre éditeur de texte alternatif préféré.

sudo nano /etc/pam.d/sshd

Ajouter la ligne suivante au bas du fichier.

. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth 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 jeton OATH-TOTP de se connecter en utilisant leur clé SSH. Une fois que tous les utilisateurs ont un jeton OATH-TOTP, vous pouvez supprimer nullok de cette ligne pour rendre MFA obligatoire.

Enregistrez et fermez le fichier.

Puis, nous allons configurer SSH pour qu’il prenne en charge ce type d’authentification. Ouvrez le fichier de configuration SSH pour le modifier.

sudo nano /etc/ssh/sshd_config

Regardez les lignes ChallengeResponseAuthentication. Mettez en commentaire la ligne no et décommentez la ligne no.

. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

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, vous ne risquez donc pas de vous bloquer avec cette commande.

sudo systemctl restart sshd.service

Pour vérifier 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 à taper le mot de passe de votre utilisateur ou 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 dû obtenir une invite de mot de passe et de code de vérification.

Si vous voulez vous assurer que ce que vous avez fait jusqu’à présent fonctionne, dans votre session SSH ouverte, naviguez vers ~/.ssh/ et renommez le fichier authorized_keys, temporairement, et ouvrez une nouvelle session et connectez-vous avec notre mot de passe et notre code de vérification.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Une fois que vous avez vérifié que votre jeton TOTP fonctionne, renommez le fichier ‘authorized_keys.bak’ à ce qu’il était.

mv authorized_keys.bak authorized_keys

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

Étape 3 – Rendre SSH conscient de MFA

Réouvrez le fichier de configuration sshd.

sudo nano /etc/ssh/sshd_config

Ajoutez la ligne suivante au bas du fichier. Cela indique à SSH quelles méthodes d’authentification sont requises. 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 les trois).

. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

Enregistrez et fermez le fichier.

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

sudo nano /etc/pam.d/sshd

Repérez la ligne auth substack password-auth vers le haut du fichier. Mettez-la en commentaire en ajoutant un caractère # comme premier caractère de la ligne. Cela indique à PAM de ne pas demander de mot de passe.

. . .#auth substack password-auth. . .

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

sudo systemctl restart sshd.service

Maintenant essayez de vous connecter à nouveau au serveur avec une session différente. Contrairement à la dernière fois, SSH devrait vous demander votre code de vérification. En le saisissant, 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 voulez vérifier, vous pouvez ajouter -v (pour verbose) après la commande SSH:

Example SSH output\
. . .debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /Users/sammy/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 279Authenticated with partial success.debug1: Authentications that can continue: keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification 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 voulez appliquer les trois types d’authentification, vous pouvez suivre l’étape suivante.

Étape 4 – Ajout d’un troisième facteur (facultatif)

À l’étape 3, nous avons répertorié les types d’authentification approuvés dans le fichier sshd_config :

1. publickey (clé SSH)
2. password publickey (mot de passe)
3. keyboard-interactive (code de vérification)

Bien que nous ayons listé 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), une modification rapide les activera tous les trois.

Ouvrir le fichier de configuration PAM sshd.

sudo nano /etc/pam.d/sshd

Localiser la ligne que vous avez commentée précédemment, #auth substack password-auth, et décommenter la ligne en supprimant le caractère #. Enregistrez et fermez le fichier. Maintenant, une fois de plus, redémarrez SSH.

sudo systemctl restart sshd.service

En activant l’option auth substack password-auth, PAM demandera maintenant 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 précédemment. Maintenant, nous pouvons utiliser quelque chose que nous connaissons (mot de passe) et deux types différents de choses que nous avons (clé SSH et code de vérification) sur deux canaux différents.

Jusqu’ici, cet article a décrit comment activer MFA avec une clé SSH et un mot de passe unique basé sur le temps. Si c’est tout ce dont vous avez besoin, vous pouvez terminer ici. Cependant, ce n’est pas la seule façon de faire de l’authentification multifactorielle. Vous trouverez ci-dessous quelques façons supplémentaires d’utiliser ce module PAM pour l’authentification multifactorielle et quelques conseils et astuces pour la récupération, l’utilisation automatisée, et plus encore.

Conseil 1 – Récupérer l’accès

Comme pour 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 ta clé SSH ou ta clé secrète TOTP et s’assurer que tu as accès à ton appli TOTP. Cependant, il arrive parfois que des choses se produisent, et tu peux perdre le contrôle des clés ou des applications dont tu as besoin pour entrer.

La perte d’une clé SSH ou d’une clé secrète TOTP

Si tu perds ta clé SSH ou ta clé secrète TOTP, la récupération peut être décomposée en deux étapes. La première est de se reconnecter sans connaître le code de vérification et la seconde est de trouver la clé secrète ou de la régénérer pour une connexion MFA normale.

Pour se connecter après avoir perdu la clé secrète qui génère le code de vérification sur un Droplet DigitalOcean, vous pouvez simplement utiliser la console virtuelle de votre tableau de bord pour vous connecter en utilisant votre nom d’utilisateur et votre mot de passe.

Au contraire, vous aurez besoin d’un utilisateur administratif qui a un accès sudo ; assurez-vous de ne pas activer MFA pour cet utilisateur, mais utilisez simplement une clé SSH. Si vous ou un autre utilisateur perd sa clé secrète et ne peut pas se connecter, alors l’utilisateur administratif peut se connecter et aider à récupérer ou régénérer la clé pour tout utilisateur utilisant sudo.

Une fois connecté, il y a deux façons d’aider à 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 cette 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 avec l’utilisateur touché en toute sécurité ou la clé existante a été compromise), vous pouvez supprimer carrément le fichier ~/.google-authenticator. Cela permettra à l’utilisateur de se reconnecter en utilisant un seul facteur, en supposant que vous n’avez pas renforcé l’AMF en supprimant ‘nullok’ dans le fichier ‘/etc/pam.d/sshd’. Ils peuvent alors exécuter google-authenticator pour générer une nouvelle clé.

La perte de l’accès à l’appli TOTP

Si tu dois te connecter à ton serveur mais que tu n’as pas accès à ton appli TOTP pour obtenir ton code de vérification, tu peux toujours te connecter en utilisant les codes de récupération qui ont été affichés lors de la première création de ta clé secrète. Notez que ces codes de récupération sont à usage unique. Une fois qu’ils ont été utilisés pour se connecter, ils ne peuvent plus être utilisés comme code de vérification.

Conseil 2 – Modification des paramètres d’authentification

Si tu veux modifier tes paramètres MFA après la configuration initiale, au lieu de générer une nouvelle configuration avec les paramètres mis à jour, tu peux simplement modifier le fichier ~/.google-authenticator. Ce fichier est disposé 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, changez 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 les échecs de connexion multiples (limitation du taux), supprimez la ligne " RATE_LIMIT 3 30.
• Pour modifier le seuil de la limitation du taux, retrouvez 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, retirez les cinq codes à 8 chiffres en bas du fichier.

Conseil 3 – Éviter MFA pour certains comptes

Il peut y avoir une situation dans laquelle un seul utilisateur ou quelques comptes de service (c’est-à-dire des comptes utilisés par des applications, et non des humains) ont besoin d’un accès SSH sans que MFA soit activé. Par exemple, certaines applications qui utilisent SSH, comme certains clients FTP, peuvent ne pas prendre en charge 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.

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

Pour autoriser MFA pour certains comptes et la clé SSH uniquement pour d’autres, assurez-vous que les paramètres suivants dans /etc/pam.d/sshd sont actifs.

#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Ici, auth substack password-auth est commenté parce que les mots de passe doivent être désactivés. MFA ne peut pas être forcé si certains comptes sont censés avoir MFA désactivé, donc laissez l’option nullok sur la dernière ligne.

Après avoir défini cette configuration, exécutez simplement google-authenticator comme tous les utilisateurs qui ont besoin de MFA, et ne l’exécutez pas pour les utilisateurs où seules les clés SSH seront utilisées.

Tip 4 – Automatiser la configuration avec la gestion de la configuration

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

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

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

Ceci répond à toutes les questions auxquelles nous avons répondu manuellement, l’enregistre dans un fichier, puis sort la clé secrète, le code QR et les codes de récupération. (Si vous ajoutez le drapeau -q, alors 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 mettre à la disposition de l’utilisateur.

Conseil 5 – Forcer MFA pour tous les utilisateurs

Si vous voulez forcer MFA pour tous les utilisateurs même lors de la première connexion, ou si vous préférez ne pas compter sur vos utilisateurs pour générer leurs propres clés, il y a un moyen facile 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 la création initiale du fichier de configuration, un utilisateur privilégié doit copier le fichier à la racine de chaque répertoire personnel et changer ses autorisations 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.

Avertissement : Cela peut constituer un risque de sécurité car tout le monde partage le même second facteur. Cela signifie que s’il y a une fuite, c’est comme si chaque utilisateur n’avait qu’un seul facteur. Prenez cela en considération si vous voulez utiliser cette approche.

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

1. Crée un jeton TOTP,
2. Prompt le téléchargement de l’application Google Authenticator et le scan du 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 vous assurer que le script s’exécute lorsqu’un utilisateur se connecte, vous pouvez le nommer .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 brutalement son chemin dans votre machine via SSH et considérablement augmenté la sécurité de votre machine.