Comment configurer l’authentification multifacteur pour SSH sur CentOS 7

Un "facteur d’authentification" est une information unique utilisée pour prouver que vous disposez des droits nécessaires pour effectuer une action, telle que la connexion à un système. Un canal d’authentification est la manière dont un système d’authentification fournit un facteur à l’utilisateur ou oblige celui-ci à 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 des mots de passe pour l’authentification par défaut, et la plupart des instructions de renforcement de SSH recommandent l’utilisation d’une clé SSH. Cependant, il ne s’agit toujours que d’un seul facteur. Si un mauvais acteur a compromis votre ordinateur, il peut également utiliser votre clé pour compromettre vos serveurs.

Dans ce tutoriel, nous allons configurer une authentification multi-facteurs pour lutter contre cela. L’authentification multifactorielle (MFA) requiert plusieurs facteurs pour s’authentifier ou se connecter. Cela signifie qu’un mauvais acteur devrait compromettre plusieurs choses, comme votre ordinateur et votre téléphone, pour pouvoir entrer. Les différents types de facteurs sont souvent résumés comme suit:

Un élément commun est une application OATH-TOTP, telle que Google Authenticator. OATH-TOTP (mot de passe unique à authentification ouverte) est un protocole ouvert qui génère un mot de passe à usage unique, généralement un numéro à 6 chiffres recyclé toutes les 30 secondes.

Cet article explique comment activer l’authentification SSH à l’aide d’une application OATH-TOTP en plus d’une clé SSH. La connexion à votre serveur via SSH nécessite alors deux facteurs sur deux canaux, ce qui le rend plus sécurisé qu’un mot de passe ou une clé SSH seule. De plus, nous allons passer en revue quelques cas d’utilisation supplémentaires pour MFA et quelques astuces et conseils utiles.

Pour suivre ce tutoriel, vous aurez besoin de:

Dans cette étape, nous installerons et configurerons le PAM de Google.

PAM, qui signifie «Module d’authentification adaptable», est une infrastructure d’authentification utilisée sur les systèmes Linux pour authentifier un utilisateur. Comme Google a créé une application OATH-TOTP, il a également créé un PAM qui génère des TOTP et est entièrement compatible avec n’importe quelle application OATH-TOTP, telle que Google Authenticator ou Authy.

Premièrement, nous devons ajouter le référentiel EPEL (Extra Packages for Enterprise Linux).

Ensuite, installez le PAM. Vous serez peut-être invité à accepter la clé EPEL s’il s’agit de la première utilisation du référentiel. Une fois accepté, vous ne serez plus invité à accepter la clé.

Avec le PAM installé, nous utiliserons une application auxiliaire fournie avec celui-ci pour générer une clé TOTP pour l’utilisateur auquel vous souhaitez ajouter un deuxième facteur. Cette clé est générée utilisateur par utilisateur, et non à l’échelle du système. Cela signifie que chaque utilisateur souhaitant utiliser une application d’authentification TOTP devra se connecter et exécuter l’application d’assistance pour obtenir sa propre clé. vous ne pouvez pas le lancer une seule fois pour l’activer pour tout le monde (mais vous trouverez quelques astuces à la fin de ce tutoriel pour configurer ou requérir MFA pour de nombreux utilisateurs).

Exécutez l’application d’initialisation.

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.

Ce PAM permet d’utiliser des jetons temporels ou séquentiels. L’utilisation de tokens_sequential-based signifie que le code commence à un moment donné, puis incrémente le code après chaque utilisation. Utiliser des jetons basés sur le temps signifie que le code change de manière aléatoire au bout d’un certain temps. Nous nous en tiendrons au temps, car c’est ce que prévoient des applications telles que Google Authenticator. Répondez donc «+ y +» pour oui.

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

Les questions restantes informent le PAM de son fonctionnement. Nous allons les parcourir un à un.

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

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 vous connecter avec.

Répondre oui ici permet d’avoir jusqu’à 8 codes valides dans une fenêtre mobile de quatre minutes. En répondant non, vous limitez le nombre à 3 codes valides dans une fenêtre déroulante d’une minute et demie. Sauf si vous rencontrez des problèmes avec la fenêtre d'1h30, répondre non est le choix le plus sûr.

La limitation de débit signifie qu’un attaquant distant ne peut tenter qu’un certain nombre de conjectures avant d’être bloqué. Si vous n’avez pas encore configuré la limitation de débit directement dans SSH, le faire maintenant constitue une excellente technique de durcissement.

Maintenant que le PAM de Google est installé et configuré, l’étape suivante consiste à configurer SSH pour qu’il utilise votre clé TOTP. Nous devrons informer SSH du PAM, puis configurer SSH pour l’utiliser.

Comme nous allons procéder à des modifications SSH sur SSH, il est important de ne jamais fermer votre connexion SSH initiale. Au lieu de cela, ouvrez une seconde session SSH pour effectuer des tests. Ceci permet d’éviter de vous verrouiller hors de votre serveur en cas d’erreur dans votre configuration SSH. Une fois que tout fonctionne, vous pouvez fermer toutes les sessions en toute sécurité.

Pour commencer, nous allons éditer 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é.

Ajoutez la ligne suivante au bas du fichier.

/etc/pam.d/sshd

Le mot + nullok + situé à la fin de la dernière ligne indique au PAM que cette méthode d’authentification est facultative. Cela permet aux utilisateurs sans jeton OATH-TOTP de toujours se connecter à l’aide de 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.

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

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

/ etc / ssh / sshd_config

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 risquerez donc pas de vous verrouiller avec cette commande.

Pour vérifier que tout fonctionne jusqu’à présent, ouvrez un autre terminal et essayez de vous connecter via SSH. Si vous avez déjà créé une clé SSH et l’utilisez, vous remarquerez qu’il n’est pas nécessaire de saisir votre mot de passe ou le code de vérification MFA. En effet, une clé SSH remplace toutes les autres options d’authentification par défaut. Sinon, vous devriez avoir un mot de passe et un code de vérification.

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

Une fois que vous avez vérifié le bon fonctionnement de votre jeton TOTP, renommez le fichier «registered_keys.bak».

Ensuite, nous devons activer une clé SSH en tant que facteur unique et le code de vérification en tant que second facteur, puis indiquer à SSH les facteurs à utiliser et empêcher la clé SSH de remplacer tous les autres types.

Rouvrez le fichier de configuration + sshd +.

Ajoutez la ligne suivante au bas du fichier. Cela indique à SSH les méthodes d’authentification requises. Cette ligne indique à SSH que nous avons besoin d’une clé SSH et d’un mot de passe ou d’un code de vérification (ou des trois).

/ etc / ssh / sshd_config

Enregistrez et fermez le fichier.

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

Recherchez la ligne + auth substack password-auth + vers le haut du fichier. Commentez-le en ajoutant un caractère + # + en tant que premier caractère de la ligne. Cela indique à PAM de ne pas demander de mot de passe.

/etc/pam.d/sshd

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

Essayez maintenant 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 y 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 voulez vérifier, vous pouvez ajouter + -v + (pour les commentaires) après la commande SSH:

Vers la fin de la sortie, vous verrez où SSH utilise votre clé SSH, puis demande 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.

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

Bien que nous ayons énuméré trois facteurs différents, avec les options que nous avons choisies jusqu’à présent, ils ne permettent que la 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.

Ouvrez le fichier de configuration PAM + sshd +.

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

En activant l’option + auth substack password-auth +, PAM va maintenant demander un mot de passe, en plus de rechercher une clé SSH et un code de vérification, que nous avions précédemment utilisés. Nous pouvons maintenant utiliser quelque chose que nous connaissons (mot de passe) et deux types d’objets différents (clé SSH et code de vérification) sur deux canaux différents.

Jusqu’à présent, cet article a expliqué comment activer MFA avec une clé SSH et un mot de passe à utilisation unique. Si c’est tout ce dont vous avez besoin, vous pouvez vous arrêter ici. Cependant, ce n’est pas le seul moyen de faire une authentification multi-facteurs. Vous trouverez ci-dessous quelques manières supplémentaires d’utiliser ce module PAM pour une authentification multifacteur, ainsi que des conseils et astuces pour la récupération, l’utilisation automatisée, etc.

Comme avec tout système que vous renforcez 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, il arrive parfois que des événements se produisent et que vous perdiez le contrôle des clés ou des applications dont vous avez besoin pour entrer.

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:

Les options définies dans ce fichier ont une ligne dans la section des options; Si vous avez répondu «non» à une option en particulier lors de la configuration initiale, la ligne correspondante est exclue du fichier.

Voici les modifications que vous pouvez apporter à ce fichier:

Il peut y avoir une situation dans laquelle un seul utilisateur ou quelques comptes de service (c’est-à-dire les comptes utilisés par les applications, et non les humains) nécessitent un accès SSH sans MFA activé. Par exemple, certaines applications utilisant SSH, comme certains clients FTP, peuvent ne pas prendre en charge MFA. Si une application ne dispose d’aucun moyen pour demander le code de vérification, la demande peut rester bloquée jusqu’à ce que la connexion SSH expire.

Tant que quelques options de + / etc / pam.d / sshd + sont définies correctement, vous pouvez contrôler les facteurs utilisés 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.

/etc/pam.d/sshd

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

Après avoir défini cette configuration, exécutez simplement + google-authenticator + en tant qu’utilisateur ayant besoin de MFA, et ne l’exécutez pas pour les utilisateurs utilisant uniquement des clés SSH.

De nombreux administrateurs système utilisent les outils de gestion de la https://www.digitalocean.com/community/tutorial_series/getting-started-with-configuration-management, tels que 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 du compte d’un nouvel utilisateur, il existe une méthode pour ce 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. Vous trouverez ci-dessous la commande qui configurera tout comme décrit à l’étape 1:

Cela répond à toutes les questions auxquelles nous avons répondu manuellement, l’enregistre dans un fichier, puis affiche la clé secrète, le code QR et les codes de récupération. (Si vous ajoutez l’indicateur + -q +, il n’y aura aucune 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.

Si vous souhaitez 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 existe un moyen simple de gérer cela. Vous pouvez simplement utiliser le même fichier + .google-authenticator + pour chaque utilisateur, car aucune donnée spécifique à l’utilisateur n’est stockée dans le fichier.

Pour ce faire, après la création initiale du fichier de configuration, un utilisateur privilégié doit le copier à la racine de chaque répertoire de base et modifier ses autorisations en faveur de l’utilisateur approprié. Vous pouvez également copier le fichier dans + / etc / skel + / afin qu’il soit automatiquement copié dans le répertoire personnel du 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:

Pour vous assurer que le script est exécuté lorsqu’un utilisateur se connecte, vous pouvez le nommer + .bash_login + et placez-le à la racine de son répertoire de base.

Cela dit, en disposant de deux facteurs (clé SSH + jeton MFA) sur deux canaux (votre ordinateur et votre téléphone), il est très difficile pour un agent extérieur d’entrer brutalement dans votre machine via SSH, ce qui augmente considérablement la sécurité de votre machine.