Un mot de passe seul ne suffit plus à protéger un serveur SSH exposé sur Internet. Les attaques par brute-force et les fuites de credentials sont quotidiennes. L'authentification à deux facteurs (2FA) ajoute une couche de sécurité décisive : même si votre mot de passe est compromis, l'attaquant ne pourra pas se connecter sans le code temporaire généré par votre appareil physique. Ce tutoriel vous guide pas à pas dans la mise en place du 2FA sur SSH avec Google Authenticator.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
- Un serveur Linux (Debian, Ubuntu, CentOS ou dérivé) avec un accès root ou sudo
- Le service SSH installé et fonctionnel (OpenSSH Server)
- Un smartphone avec une application TOTP installée (Google Authenticator, Authy, FreeOTP, etc.)
- Un accès console alternatif au serveur (KVM, IPMI, console cloud) en cas de verrouillage
- Le service NTP activé pour garantir la synchronisation de l'horloge
Gardez toujours une session SSH ouverte pendant la configuration du 2FA. Ne fermez jamais votre session active avant d'avoir vérifié que la nouvelle configuration fonctionne dans une seconde connexion. Une erreur de configuration peut vous empêcher définitivement d'accéder à votre serveur.
Fonctionnement du protocole TOTP
TOTP (Time-based One-Time Password) est un algorithme défini par la RFC 6238 qui génère des mots de passe à usage unique basés sur le temps. Le principe repose sur un secret partagé entre le serveur et votre appareil mobile.
Le fonctionnement est le suivant :
- Lors de la configuration, un secret partagé (clé de 160 bits encodée en Base32) est généré côté serveur et transmis à votre application mobile via un QR code
- À chaque intervalle de 30 secondes, l'application et le serveur calculent indépendamment un code à 6 chiffres en appliquant l'algorithme HMAC-SHA1 sur le secret combiné à l'horodatage courant
- Lors de la connexion, le serveur compare le code que vous saisissez avec celui qu'il a calculé. Si les deux correspondent, l'authentification est validée
L'avantage majeur de TOTP est qu'il ne nécessite aucune connectivité réseau sur l'appareil mobile : le calcul se fait entièrement hors ligne, seule la synchronisation de l'horloge est requise.
Installation de libpam-google-authenticator
Le module PAM de Google Authenticator est disponible dans les dépôts officiels de la plupart des distributions Linux.
Sur Debian / Ubuntu :
sudo apt update
sudo apt install libpam-google-authenticator -y
Sur CentOS / RHEL / Rocky Linux :
sudo dnf install epel-release -y
sudo dnf install google-authenticator -y
Sur Arch Linux :
sudo pacman -S libpam-google-authenticator
Vérifiez que le module PAM est bien installé :
ls /lib/security/pam_google_authenticator.so
# ou sur certaines distributions :
ls /lib64/security/pam_google_authenticator.so
Configuration de Google Authenticator
Exécutez la commande de configuration en tant que l'utilisateur qui se connectera en SSH (pas en root, sauf si vous vous connectez en root) :
google-authenticator
L'assistant interactif vous posera plusieurs questions :
Do you want authentication tokens to be time-based (y/n) y
# Un QR code ASCII s'affiche ici
# Scannez-le avec votre application TOTP
Your new secret key is: JBSWY3DPEHPK3PXP
Enter code from app (-1 to skip): 123456
Your emergency scratch codes are:
12345678
87654321
11223344
44332211
99887766
Do you want me to update your "/home/user/.google_authenticator" file? (y/n) y
Do you want to disallow multiple uses of the same authentication token? (y/n) y
By default, a new token is generated every 30 seconds. Do you want to increase the window size? (y/n) n
Do you want to enable rate-limiting? (y/n) y
Notez immédiatement les emergency scratch codes affichés. Stockez-les dans un endroit sûr et hors ligne (coffre-fort physique, gestionnaire de mots de passe chiffré). Ces codes vous permettront de vous connecter si vous perdez l'accès à votre application TOTP.
La configuration est stockée dans le fichier ~/.google_authenticator. Ce fichier contient le secret, les options et les codes de secours restants. Protégez-le :
chmod 600 ~/.google_authenticator
ls -la ~/.google_authenticator
Configuration de PAM
PAM (Pluggable Authentication Modules) est le système qui gère l'authentification sous Linux. Nous devons y ajouter le module Google Authenticator pour SSH.
Éditez le fichier de configuration PAM pour SSH :
sudo nano /etc/pam.d/sshd
Ajoutez la ligne suivante à la fin du fichier :
auth required pam_google_authenticator.so nullok
Les options disponibles pour le module PAM sont :
nullok: permet aux utilisateurs qui n'ont pas encore configuré le 2FA de se connecter normalement. Retirez cette option une fois que tous les utilisateurs ont configuré leur 2FAno_increment_hotp: ne pas incrémenter le compteur en cas d'échec (utile en mode HOTP uniquement)noskewadj: désactive l'ajustement automatique du décalage temporelecho_verification_code: affiche le code saisi (déconseillé en production)secret=/chemin/vers/${USER}/.google_authenticator: chemin personnalisé vers le fichier de configuration
L'option
nullok est pratique lors du déploiement progressif du 2FA, mais constitue une faille de sécurité si laissée en place. Un utilisateur qui n'a pas configuré le 2FA pourra se connecter uniquement avec son mot de passe. Planifiez son retrait dès que tous les comptes sont configurés.
Configuration du serveur SSH
Modifiez la configuration du démon SSH pour activer l'authentification par défi-réponse :
sudo nano /etc/ssh/sshd_config
Modifiez ou ajoutez les directives suivantes :
# Activer l'authentification par défi-réponse (challenge-response)
KbdInteractiveAuthentication yes
# Définir les méthodes d'authentification requises
# Mot de passe + code TOTP
AuthenticationMethods keyboard-interactive
# S'assurer que UsePAM est activé
UsePAM yes
Sur les versions récentes d'OpenSSH (8.7+), la directive
ChallengeResponseAuthentication a été renommée en KbdInteractiveAuthentication. Les deux sont acceptées pour la rétrocompatibilité, mais préférez la nouvelle syntaxe.
Vérifiez la syntaxe de la configuration avant de redémarrer :
# Tester la configuration
sudo sshd -t
# Si aucune erreur, redémarrer le service
sudo systemctl restart sshd
Testez immédiatement dans un nouveau terminal (gardez votre session actuelle ouverte) :
ssh utilisateur@votre-serveur
Vous devriez voir apparaître une demande de mot de passe suivie d'une demande de code de vérification :
Password:
Verification code:
2FA combiné avec les clés SSH
La configuration la plus sécurisée combine l'authentification par clé SSH et le code TOTP. L'utilisateur doit alors présenter deux facteurs : quelque chose qu'il possède (la clé privée) et quelque chose qu'il connaît/génère (le code TOTP).
Modifiez /etc/ssh/sshd_config :
# Authentification par clé SSH + code TOTP
AuthenticationMethods publickey,keyboard-interactive
# Activer les deux méthodes
PubkeyAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
Ensuite, modifiez /etc/pam.d/sshd pour commenter ou supprimer la ligne d'authentification par mot de passe standard, afin que PAM ne demande que le code TOTP :
# Commenter cette ligne pour ne pas demander le mot de passe via PAM
# @include common-auth
# Le module Google Authenticator demande uniquement le code TOTP
auth required pam_google_authenticator.so
Le flux de connexion sera alors :
- Le client présente sa clé SSH publique (vérification automatique)
- Si la clé est acceptée, le serveur demande le code TOTP via keyboard-interactive
- L'utilisateur saisit son code à 6 chiffres
- La connexion est établie si les deux facteurs sont validés
# Redémarrer SSH après modification
sudo sshd -t && sudo systemctl restart sshd
Exemptions pour certains utilisateurs
Certains comptes (services automatisés, scripts de déploiement, monitoring) ne peuvent pas fournir de code TOTP. Utilisez les directives Match pour créer des exceptions.
Exemption par utilisateur :
# Configuration globale : clé + TOTP pour tous
AuthenticationMethods publickey,keyboard-interactive
# Exemption pour un utilisateur spécifique
Match User deploy,monitoring
AuthenticationMethods publickey
Exemption par groupe :
# Créer un groupe pour les comptes exemptés
sudo groupadd ssh-notp
# Ajouter les utilisateurs au groupe
sudo usermod -aG ssh-notp deploy
sudo usermod -aG ssh-notp monitoring
# Dans sshd_config
Match Group ssh-notp
AuthenticationMethods publickey
Exemption par adresse IP (réseau interne par exemple) :
# Pas de 2FA depuis le réseau local
Match Address 192.168.1.0/24,10.0.0.0/8
AuthenticationMethods publickey
Chaque exemption est une surface d'attaque potentielle. Limitez les comptes exemptés au strict minimum, utilisez des clés SSH fortes (Ed25519) pour ces comptes, et auditez régulièrement la liste des exemptions. Préférez l'exemption par groupe pour faciliter la gestion.
Applications TOTP recommandées
Le module PAM google-authenticator est compatible avec toute application respectant la RFC 6238. Voici les principales options :
- Google Authenticator (Android/iOS) : simple et efficace, mais pas de sauvegarde cloud native. Si vous changez de téléphone, vous devez reconfigurer chaque compte
- Authy (Android/iOS/Desktop) : sauvegarde cloud chiffrée, synchronisation multi-appareils. Idéal si vous gérez plusieurs serveurs
- FreeOTP (Android/iOS) : open source, développé par Red Hat. Pas de sauvegarde cloud, ce qui est un avantage pour la sécurité
- Bitwarden Authenticator : intégré au gestionnaire de mots de passe Bitwarden, centralise credentials et codes TOTP
- KeePassXC (Desktop) : gestionnaire de mots de passe local avec support TOTP intégré, idéal pour une approche 100% hors ligne
Pour ajouter manuellement un compte (sans QR code), utilisez le secret affiché lors de la commande google-authenticator et configurez :
- Type : TOTP (basé sur le temps)
- Algorithme : SHA1
- Chiffres : 6
- Période : 30 secondes
Gestion des codes de secours
Les codes de secours (scratch codes) sont votre filet de sécurité. Chaque code ne peut être utilisé qu'une seule fois et est supprimé du fichier ~/.google_authenticator après utilisation.
Vérifier les codes restants :
# Les codes de secours sont les lignes de 8 chiffres dans le fichier
# Les 5 dernières lignes après les options
tail -5 ~/.google_authenticator
Régénérer les codes de secours (relance complète de la configuration) :
# Reconfigurer entièrement Google Authenticator
google-authenticator
Relancer
google-authenticator génère un nouveau secret. Vous devrez rescanner le QR code dans votre application TOTP. L'ancien secret et les anciens codes de secours seront invalidés. Assurez-vous de mettre à jour votre application mobile immédiatement.
Bonnes pratiques pour les codes de secours :
- Stockez-les dans un gestionnaire de mots de passe chiffré (KeePassXC, Bitwarden)
- Imprimez-les et conservez-les dans un coffre-fort physique
- Ne les stockez jamais sur le serveur lui-même
- Régénérez-les dès qu'il n'en reste plus que 2
- Testez régulièrement qu'un code de secours fonctionne
Sécurisation avancée
Renforcez la configuration TOTP avec des options supplémentaires.
Rate limiting (limitation du nombre de tentatives) :
Lors de la configuration initiale, répondez y à la question sur le rate-limiting. Cela limite à 3 tentatives de connexion toutes les 30 secondes. Vous pouvez aussi éditer directement le fichier :
# Vérifier que le rate limiting est actif dans ~/.google_authenticator
# La ligne suivante doit être présente :
# " RATE_LIMIT 3 30
grep RATE_LIMIT ~/.google_authenticator
Window size (tolérance temporelle) :
Par défaut, le serveur accepte le code courant plus le code précédent et suivant (window size de 1, soit 3 codes valides). Sur un réseau à latence élevée, vous pouvez augmenter cette fenêtre :
# Dans ~/.google_authenticator, modifier ou ajouter :
# " WINDOW_SIZE 3
# Accepte les 3 codes précédents et suivants (soit 7 codes valides)
# Plus la fenêtre est grande, moins la sécurité est forte
Interdire la réutilisation de tokens :
# La ligne suivante dans ~/.google_authenticator interdit la réutilisation
# " DISALLOW_REUSE
grep DISALLOW_REUSE ~/.google_authenticator
Fail2ban pour le 2FA :
Configurez Fail2ban pour bloquer les tentatives répétées de 2FA :
# /etc/fail2ban/jail.local
# [sshd]
# enabled = true
# port = ssh
# filter = sshd
# logpath = /var/log/auth.log
# maxretry = 3
# bantime = 3600
# findtime = 600
sudo systemctl restart fail2ban
Dépannage
Problème : verrouillé hors du serveur
Si vous ne pouvez plus vous connecter en SSH :
- Accédez au serveur via la console physique, KVM, IPMI ou la console web de votre hébergeur
- Désactivez temporairement le 2FA :
# Option 1 : commenter le module PAM
sudo nano /etc/pam.d/sshd
# Commenter la ligne : auth required pam_google_authenticator.so
# Option 2 : revenir à l'authentification simple
sudo nano /etc/ssh/sshd_config
# Modifier : AuthenticationMethods password
# Redémarrer SSH
sudo systemctl restart sshd
Problème : le code TOTP est toujours refusé
Vérifiez la synchronisation de l'horloge :
# Vérifier le statut NTP
timedatectl status
# Si NTP n'est pas synchronisé
sudo timedatectl set-ntp true
# Forcer une synchronisation immédiate
sudo systemctl restart systemd-timesyncd
# Vérifier l'heure actuelle
date -u
Problème : debug de la configuration PAM
Activez le mode debug pour diagnostiquer les problèmes :
# Dans /etc/pam.d/sshd, ajouter debug au module
auth required pam_google_authenticator.so debug
# Suivre les logs en temps réel pendant une tentative de connexion
sudo tail -f /var/log/auth.log
# Sur les systèmes avec journald
sudo journalctl -u sshd -f
Problème : le serveur ne demande pas le code TOTP
# Vérifier que KbdInteractiveAuthentication est bien à yes
sudo sshd -T | grep kbdinteractiveauthentication
# Vérifier que UsePAM est activé
sudo sshd -T | grep usepam
# Vérifier que le fichier .google_authenticator existe pour l'utilisateur
ls -la ~/.google_authenticator
# Vérifier les permissions (doit être 600 ou 400)
stat -c "%a %U" ~/.google_authenticator
Problème : "Permission denied" après configuration
# Vérifier les permissions du répertoire home
# SELinux ou AppArmor peuvent bloquer l'accès
ls -laZ ~/.google_authenticator
# Sur SELinux, restaurer le contexte
sudo restorecon -Rv ~/.google_authenticator
# Vérifier que le répertoire home n'est pas world-writable
ls -ld ~
Utilisez toujours
sudo sshd -T (avec un T majuscule) pour afficher la configuration effective du serveur SSH. Cela prend en compte tous les fichiers inclus et les directives Match. Comparez la sortie avec vos attentes pour identifier les divergences.
Conclusion
L'authentification à deux facteurs sur SSH est une mesure de sécurité essentielle pour tout serveur exposé sur Internet. La combinaison clé SSH + TOTP offre le meilleur niveau de protection en exigeant à la fois un facteur de possession (la clé privée et le téléphone) et un facteur temporel (le code TOTP).
Pour récapituler les points clés :
- Installez
libpam-google-authenticatoret configurez chaque utilisateur individuellement - Privilégiez la combinaison
publickey,keyboard-interactivepour une sécurité maximale - Conservez vos codes de secours hors ligne et en sécurité
- Utilisez
nullokuniquement pendant la phase de déploiement - Maintenez la synchronisation NTP sur tous vos serveurs
- Testez systématiquement dans une nouvelle session avant de fermer la session active
- Complétez le 2FA avec Fail2ban pour une défense en profondeur
Le temps investi dans cette configuration est minime comparé à la protection qu'elle apporte. Un code à 6 chiffres saisi en quelques secondes peut faire la différence entre un serveur sécurisé et une compromission totale.
Commentaires