Security
Difficulte: Intermediate
13 min de lecture

2FA SSH : Authentification à deux facteurs avec Google Authenticator

Configurez l'authentification à deux facteurs sur SSH avec Google Authenticator pour renforcer la sécurité de vos serveurs Linux.

Retour aux tutoriels
Pourquoi le 2FA est indispensable
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
Risque de verrouillage
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 :

  1. 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
  2. À 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
  3. 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
Codes de secours
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 2FA
  • no_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 temporel
  • echo_verification_code : affiche le code saisi (déconseillé en production)
  • secret=/chemin/vers/${USER}/.google_authenticator : chemin personnalisé vers le fichier de configuration
Option nullok
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
Note sur ChallengeResponseAuthentication
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 :

  1. Le client présente sa clé SSH publique (vérification automatique)
  2. Si la clé est acceptée, le serveur demande le code TOTP via keyboard-interactive
  3. L'utilisateur saisit son code à 6 chiffres
  4. 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
Sécurité des exemptions
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
Attention
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 :

  1. Accédez au serveur via la console physique, KVM, IPMI ou la console web de votre hébergeur
  2. 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 ~
Conseil de debug
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-authenticator et configurez chaque utilisateur individuellement
  • Privilégiez la combinaison publickey,keyboard-interactive pour une sécurité maximale
  • Conservez vos codes de secours hors ligne et en sécurité
  • Utilisez nullok uniquement 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.

Morgann Riu

Écrit par

Morgann Riu

Expert en cybersécurité et administration Linux. Je partage mes connaissances à travers des tutoriels gratuits et des formations pour aider les administrateurs systèmes et développeurs à sécuriser leurs infrastructures.

Partager ce tutoriel

Cet article vous a plu ?

Commentaires

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.