Comment activer la vérification en deux étapes pour les connexions SSH

Si vous voulez vraiment sécuriser votre serveur cloud, vous pouvez activer l'authentification à deux facteurs pour SSH de la même manière que vous l'ajouteriez à votre compte Gmail, empêchant quiconque d'accéder à votre serveur s'ils ont volé votre clé privée SSH.

Est-ce vraiment nécessaire ?

Comparé à l'utilisation de l'authentification à deux facteurs sur un compte email ou web, l'authentification à deux facteurs sur SSH n'est pas aussi utile. Pour quelque chose comme un email, le point de défaillance est généralement les systèmes de réinitialisation de mot de passe, les mots de passe facilement craquables ou les violations de données. En réalité, tout ce qui concerne les mauvais mots de passe ou la gestion médiocre des mots de passe.

Pour SSH, ce n'est pas vraiment un problème. SSH utilise un chiffrement très efficace pour les clés publiques et privées qu'il utilise pour établir des connexions. Si votre serveur SSH est sécurisé et n'autorise pas l'accès par mot de passe, personne ne pourra y accéder à moins d'avoir l'appareil physique sur lequel se trouve la clé, et il est peu probable que quelqu'un puisse craquer votre clé SSH de sitôt. Donc, en un sens, c'est presque comme si vous aviez déjà une authentification à deux facteurs, car votre clé restera sur votre ordinateur portable.

Mais, dans certains cas marginaux, l'authentification à deux facteurs peut être un bon choix. Si un hacker fou décide de voler votre ordinateur portable avec l'intention de s'emparer de vos clés SSH ainsi que de celui-ci (et pas seulement de le vendre sur Craigslist lorsqu'il ne peut pas cracker le mot de passe de votre appareil), avoir une authentification à deux facteurs vous mettrait une étape en avance.

Un problème plus concret cependant concerne le transfert d'agent SSH ; avec le transfert d'agent activé, les demandes de clés pour se connecter à des serveurs supplémentaires sont renvoyées à votre appareil. Cela vous permet de vous connecter par SSH à un serveur public, et---depuis ce serveur public---de vous connecter à nouveau par SSH à un autre serveur privé sur le même réseau, vous donnant un accès similaire à celui d'un VPN.

Le problème, cependant, est que si le serveur public est compromis, si vous avez le transfert d'agent activé, un attaquant peut agir en votre nom pendant que vous êtes connecté au serveur public. Cela constitue une potentiales élévation de privilèges, selon la façon dont vous avez configuré votre réseau. L'authentification SSH à deux facteurs résoudrait ce problème.

Encore une fois, c'est une solution très spécifique, et elle causera probablement plus de problèmes qu'elle n'en prévient, mais si vous êtes sérieux au sujet de sécuriser tout, nous vous montrerons comment faire.

Comment activer l'authentification à deux facteurs pour SSH

Pour gérer les demandes à deux facteurs, nous utiliserons le module d'authentification pluggable de Google (PAM), qui fonctionne avec Authy et Google Authenticator. Installez-le à partir du gestionnaire de paquets de votre distribution :

sudo apt-get install libpam-google-authenticator

Ensuite, exécutez cette commande d'initialisation :

google-authenticator

Répondez oui à la première question concernant le fait que les jetons d'authentification soient basés sur le temps. C'est plus sécurisé. Votre terminal sera ensuite inondé d'un gigantesque code QR, et vous devrez probablement dézoomer un peu.

Ouvrez votre application d'authentification et scannez votre code (pas la capture d'écran). Votre application devrait se synchroniser et commencer à générer des codes à six chiffres qui changent toutes les 30 secondes.

Vous voudrez également prendre note de toutes les sorties supplémentaires, y compris la clé secrète et les codes de secours d'urgence. Ceux-ci sont utilisés pour regagner l'accès à votre serveur si vous êtes verrouillé à l'extérieur pour une raison quelconque, bien que vous deviez être averti que tout problème lié à une mauvaise configuration peut toujours vous laisser bloqué de façon permanente. Nous allons activer l'authentification à deux facteurs de manière optionnelle pour des tests avant de la rendre obligatoire.

Pour les prochaines questions, répondez comme suit :

• Répondez oui à la mise à jour de votre configuration, sinon rien ne fonctionnera.
• Répondez oui pour interdire les utilisations multiples de chaque jeton. Ils devraient expirer une fois utilisés.
• Répondez non à l'extension de la période de validité du code, car cela n'a vraiment pas de sens.
• Répondez oui pour permettre la limitation de vitesse, ce qui bloquera les attaquants après trois tentatives. Vos trois derniers codes seront valides pendant une minute et demie, donc vous n'aurez pas à vous inquiéter de vous verrouiller à l'extérieur en étant trop lent.

Toute votre configuration est enregistrée dans ~/.google-authenticator. Vous pouvez copier ce fichier sur un serveur supplémentaire pour appliquer la même configuration ; ne relancez pas l'outil d'initialisation, sinon vous devrez lier deux appareils séparés.

Configurer SSH pour fonctionner avec Google PAM

Ouvrez le fichier de configuration PAM à /etc/pam.d/sshd dans votre éditeur de texte préféré, et ajoutez la ligne suivante tout en bas :

auth required pam_google_authenticator.so nullok

La directive nullok signifie que c'est temporaire, donc la vérification à deux facteurs sera facultative jusqu'à ce que vous changiez cela. Laissez-le ainsi pour les tests. Vous voudrez également trouver la ligne qui contient @include common-auth, et la commenter avec un # :

Standard Un*x authentication.


#@include common-auth

Cela désactive l'authentification par mot de passe, ce que vous ne voulez pas.

Ensuite, ouvrez les paramètres de SSH à /etc/ssh/sshd_config. Trouvez l'option ChallengeResponseAuthentication et activez-la :

Change to yes to enable challenge-response passwords (beware issues with


some PAM modules and threads)

ChallengeResponseAuthentication yes

Ceci active l'authentification à deux facteurs (2FA), cependant, les clés SSH contournent 2FA par défaut, donc vous devrez corriger cela en ajoutant la ligne suivante à la fin de sshd_config:

AuthenticationMethods publickey,keyboard-interactive

Cela nécessite une clé publique et "interactive au clavier", qui est l'invite qui vous demande votre code à deux facteurs.

SSH est maintenant configuré, vous pouvez donc redémarrer sshd pour activer ces nouveaux paramètres :

sudo systemctl restart sshd.service

Cela ne fermera pas votre connexion ouverte, donc vous devriez faire tout test de connexion dans un onglet de terminal séparé. Ouvrez un nouvel onglet et essayez de vous connecter à votre serveur. Vous devriez voir une invite demandant un code de vérification. Entrez-en un depuis votre téléphone, et si tout est bien lié, cela devrait fonctionner. Si ce n'est pas le cas, vous devriez quand même pouvoir accéder au compte en laissant le champ vide.

Si tout fonctionne correctement, et que vous avez vérifié qu'il n'y a pas de problème pour vous connecter, vous pouvez supprimer la directive "nullok" dans /etc/pam.d/sshd pour rendre l'authentification à deux facteurs obligatoire.

Si vous perdez l'accès, vous pouvez toujours vous connecter en utilisant les codes d'urgence qui vous ont été donnés lorsque vous avez configuré PAM, et la clé secrète devrait vous permettre de relier une application TOTP si la vôtre devenait déliée pour une raison quelconque.

Ajouter un accès pour les comptes de service

Si vous avez un compte de service qui doit accéder à votre serveur (par exemple, rsync), vous devez désactiver l'authentification à deux facteurs pour ce compte. C'est assez facile à faire ; d'abord, nous allons vouloir créer un nouveau groupe pour ajouter des comptes de service :

sudo groupadd service

Puis ajoutez l'utilisateur à ce groupe :

sudo useradd <username>


sudo usermod -a -G service <username>

Ensuite, ouvrez la configuration PAM à /etc/pam.d/sshd, et ajoutez la ligne suivante:

auth [success=done default=ignore] pam_succeed_if.so user ingroup service

Veuillez noter que cela permet d'accéder à votre serveur sans la 2FA, mais si l'utilisateur n'est pas root, cela peut ne pas être un gros problème.