Comment configurer l’authentification multifacteur pour SSH sur CentOS 7

introduction

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:

  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 application d’authentification ou un jeton de sécurité

  3. Quelque chose que vous êtes, comme votre empreinte digitale ou votre voix

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.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

  • Un serveur CentOS 7 avec un utilisateur sudo non root et une clé SSH, que vous pouvez configurer en suivant les instructions suivantes: this Tutoriel d’installation du serveur.

  • Un smartphone ou une tablette avec une application OATH-TOTP installée, telle que Google Authenticator (iOS, https://play.google .com / store / apps / details? id = com.google.android.apps.authenticator2 & hl = fr [Android]).

Étape 1 - Installation du PAM de Google

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

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

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

sudo yum install google-authenticator

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.

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.

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

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.

OutputDo you want me to update your "/home/sammy/.google_authenticator" file (y/n)

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.

OutputDo 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)

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.

OutputBy default, tokens are good for 30 seconds. 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 +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens).
Do you want to do so? (y/n)

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.

OutputIf 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)

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.

Étape 2 - Configuration d’OpenSSH

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

sudo nano /etc/pam.d/sshd

Ajoutez la ligne suivante au bas du fichier.

/etc/pam.d/sshd

. . .
# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare

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.

sudo nano /etc/ssh/sshd_config

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

/ etc / ssh / sshd_config

. . .
# Change to no to disable s/key passwords

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

cd ~/.ssh
mv authorized_keys authorized_keys.bak

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

mv authorized_keys.bak authorized_keys

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.

Étape 3 - Sensibilisation de SSH à MFA

Rouvrez le fichier de configuration + sshd +.

sudo nano /etc/ssh/sshd_config

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

. . .
# Added by DigitalOcean build process
ClientAliveInterval 120
ClientAliveCountMax 2

Enregistrez et fermez le fichier.

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

sudo nano /etc/pam.d/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

. . .
auth       substack     password-auth
. . .

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

sudo systemctl restart sshd.service

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:

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 ssh-rsa blen 279
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Verification code:

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.

É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. + mot de passe publickey + (mot de passe)

  3. + keyboard-interactive + (code de vérification)

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

sudo nano /etc/pam.d/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.

sudo systemctl restart sshd.service

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.

Astuce 1 - Récupération d’accès

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.

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 scindée en deux étapes. La première consiste à rentrer sans connaître le code de vérification et la seconde à rechercher la clé secrète ou à la régénérer pour la connexion MFA normale.

Pour entrer après avoir perdu la clé secrète qui génère le code de vérification sur un droplet DigitalOcean, vous pouvez simplement https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-console-toaccess -your-droplet [utilisez la console virtuelle] de votre tableau de bord pour vous connecter à l’aide de votre nom d’utilisateur et de votre mot de passe.

Sinon, vous aurez besoin d’un administrateur qui dispose d’un accès sudo; Veillez à ne pas activer MFA pour cet utilisateur, mais utilisez uniquement une clé SSH. Si vous ou un autre utilisateur perdez sa clé secrète et ne pouvez plus vous connecter, l’administrateur peut se connecter et aider à récupérer ou régénérer la clé pour tout utilisateur utilisant + sudo +.

Une fois que vous êtes connecté, vous pouvez obtenir le secret TOTP de deux manières:

  1. Récupérer la clé existante

  2. Générer une nouvelle clé

Dans le répertoire de base 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é consiste à 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//.google_authenticator

S’il existe une raison de ne pas utiliser la clé existante (par exemple, l’impossibilité de partager facilement la clé secrète avec l’utilisateur concerné ou si la clé existante a été compromise), vous pouvez supprimer le fichier + ~ / .google-authenticator +. carrément. Cela permettra à l’utilisateur de se reconnecter en utilisant un seul facteur, en supposant que vous n’ayez pas imposé la norme MFA en supprimant "nullok" dans le fichier "/etc/pam.d/sshd". Ils peuvent ensuite exécuter + google-authentator pour générer une nouvelle clé.

Perdre l’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 à l’aide des codes de récupération qui vous ont été affichés lors de la création de votre clé secrète. Notez que ces codes de récupération sont à usage unique. Une fois que l’on est utilisé pour se connecter, il ne peut plus être utilisé comme code de vérification.

Astuce 2 - Modification des 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:

google-authenticator layout
<secret key>
<options>
<recovery codes>

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:

  • 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 autoriser plusieurs utilisations d’un même 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 connexions échouées (limitation de débit), supprimez la ligne `+" RATE_LIMIT 3 30 + `.

  • Pour modifier le seuil de limitation de débit, recherchez la ligne `" RATE_LIMIT 3 30 + `et ajustez les nombres. Le « 3 » de l'original indique le nombre de tentatives sur une période donnée et le « 30 +» indique la période en secondes.

  • Pour désactiver l’utilisation des codes de récupération, supprimez les cinq codes à 8 chiffres au bas du fichier.

Astuce 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 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

#%PAM-1.0
auth       required     pam_sepermit.so
#auth       substack     password-auth

. . .

# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare
auth       required      pam_google_authenticator.so nullok

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.

Astuce 4 - Automatisation de la configuration avec Configuration Management

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:

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

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.

Astuce 5 - Forcer MFA pour tous les utilisateurs

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:

  1. Crée un jeton TOTP,

  2. Les invite à télécharger l’application Google Authenticator et à scanner le code QR qui sera affiché, et

  3. Lance 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 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.

Conclusion

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.