Comment activer deux facteurs pour les connexions SSH

Si vous voulez vraiment pour verrouiller 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'y accéder s'il a volé votre clé privée SSH.

Est-ce vraiment nécessaire ?

Comparé à deux facteurs sur un compte de messagerie ou sur le Web, deux facteurs sur SSH ne sont pas aussi utiles. Pour quelque chose comme le courrier électronique, le point d'échec est généralement les schémas de réinitialisation de mot de passe, les mots de passe facilement piratables ou les violations de données. Vraiment, tout ce qui implique de mauvais mots de passe ou une mauvaise gestion des mots de passe.

Pour SSH, ce n'est pas vraiment un problème. SSH utilise un très bon cryptage pour les clés publiques et privées qu'il utilise pour établir des connexions. Si votre serveur SSH est verrouillé et n'autorise pas l'accès par mot de passe, personne n'entre à moins d'avoir le périphérique physique sur lequel se trouve la clé, et il est peu probable que quelqu'un force brutalement votre clé SSH n'importe quand ce siècle. Donc, dans un sens, c'est presque comme si vous aviez déjà deux facteurs, car votre clé restera sur votre ordinateur portable.

Mais, dans certains cas marginaux, deux facteurs peuvent être un bon choix. Si un hacker lunatique décide de voler votre ordinateur portable avec l'intention de récupérer vos clés SSH avec lui (et pas seulement de le vendre sur Craigslist quand ils ne peuvent pas déchiffrer le mot de passe de votre appareil), avoir deux facteurs vous donnerait une longueur d'avance .

Un problème plus réel concerne le transfert d'agent SSH ; Lorsque le transfert d'agent est activé, les demandes de clé pour se connecter à des serveurs supplémentaires sont renvoyées vers votre appareil. Cela vous permet de vous connecter en SSH à un serveur public, et à partir de ce serveur public de SSH à nouveau vers un autre serveur privé sur le même réseau, vous donnant un accès similaire au fonctionnement d'un VPN.

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

Encore une fois, il s'agit d'une solution de cas très marginale, et causera probablement plus de problèmes qu'elle n'en empêche, mais si vous voulez vraiment tout verrouiller, nous #8217;Je vais vous montrer comment.

Comment activer deux facteurs pour SSH

Pour gérer les demandes à deux facteurs, nous utiliserons le module d'authentification enfichable (PAM) de Google, qui fonctionne avec Authy et Google Authenticator. Installez-le à partir du gestionnaire de packages 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 sur le fait que les jetons d'authentification soient basés sur le temps. C'est plus sûr. Votre terminal sera alors inondé d'un code QR gigantesque, et vous devrez probablement effectuer un zoom arrière.

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

Vous voudrez également noter toutes les sorties supplémentaires, y compris la clé secrète et les codes à gratter d'urgence. Ceux-ci sont utilisés pour accéder à nouveau à votre serveur si vous êtes bloqué pour une raison quelconque, mais vous devez être averti que tout problème lié à une mauvaise configuration peut toujours vous laisser bloqué de façon permanente. Nous allons activer deux facteurs en option pour les tests avant de les rendre obligatoires.

Pour les questions suivantes, répondez aux questions suivantes :

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 fenêtre de code valide, car cela n'a vraiment aucun sens.
Répondez oui pour autoriser la limitation du débit, qui bloquera les attaquants après trois tentatives. Vos trois derniers codes seront valides pendant une minute et demie, vous n'aurez donc pas à vous soucier de vous enfermer 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 réexécutez pas l'outil d'initialisation, ou vous devrez lier deux appareils distincts.

Configurez SSH pour qu'il fonctionne avec Google PAM

Ouvrez le fichier de configuration PAM sur /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 Publicité< br>

La directive nullok signifie que cela est temporaire, donc deux facteurs seront facultatifs 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 une authentification #:

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

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

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

# Remplacez-la par yes pour activer les mots de passe challenge-response (attention aux problèmes avec # certains modules et threads PAM) ChallengeResponseAuthentication yes

Cela active 2FA, cependant, les clés SSH remplacent 2FA par défaut, vous devrez donc résoudre ce problème en ajoutant la ligne suivante à la fin de sshd_config :

AuthenticationMethods publickey,keyboard-interactive

Cela nécessite un clé publique et “clavier-interactif,” 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 Publicité< br>

Cela ne fermera pas votre connexion ouverte, vous devez donc effectuer tous les tests 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 vous demandant un code de vérification. Entrez-en un depuis votre téléphone, et si tout est correctement lié, cela devrait fonctionner. Si ce n'est pas le cas, vous devriez toujours pouvoir accéder au compte en le laissant vide.

Si tout fonctionne correctement et que vous avez vérifié qu'il n'y a pas de problème de connexion, vous pouvez supprimer le “nullok” dans /etc/pam.d/sshd pour rendre 2FA obligatoire.

Si vous perdez l'accès, vous pouvez toujours vous connecter en utilisant les codes d'urgence qui vous ont été fournis lors de la configuration de PAM, et la clé secrète devrait permettre vous devez reconnecter une application TOTP si la vôtre devient dissociée pour quelque raison que ce soit.

Ajouter un accès pour les comptes de service

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

sudo groupadd service

Ensuite, ajouter l'utilisateur à ce groupe :

sudo useradd <username> sudo usermod -a -G service <nom d'utilisateur>

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

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

Notez que cela permet l'accès à votre serveur sans le 2FA, mais si l'utilisateur n'est pas root, ce n'est peut-être pas un gros problème.