Offre de lancement — -20% sur tous les VPS avec le code NVH20 · Déploiement en 60 secondes
Accueil / Documentation / Sécurité
Sécurité

Activer la double authentification (TOTP) sur SSH

Par Équipe NVHCloud 2026-09-18 Lecture : 4 min

Avec une clé SSH, un attaquant doit voler un fichier sur votre ordinateur. Avec la double authentification, il lui faut aussi votre téléphone. Ce guide ajoute un code à six chiffres, renouvelé toutes les 30 secondes, à chaque connexion SSH, en plus de la clé.

1. Le principe

Le standard TOTP (Time-based One-Time Password) génère des codes à partir d'un secret partagé et de l'heure. N'importe quelle application compatible fonctionne : Google Authenticator, Microsoft Authenticator, Aegis, 2FAS, ou le module TOTP d'un gestionnaire de mots de passe. Côté serveur, c'est le module PAM libpam-google-authenticator qui vérifie les codes, quelle que soit l'application utilisée.

Le résultat : la connexion exige la clé SSH, puis le code. Aucun mot de passe n'est demandé.

2. Avant de commencer

  • La connexion par clé doit déjà fonctionner, avec les mots de passe désactivés : voir sécuriser SSH.
  • L'horloge du serveur doit être juste, puisque les codes dépendent de l'heure. Vérifiez avec timedatectl : la ligne System clock synchronized doit indiquer yes.
  • Gardez une session root ouverte pendant toute la procédure.

3. Installer le module

apt install -y libpam-google-authenticator

4. Enrôler votre téléphone

La commande s'exécute avec le compte qui se connectera, pas en root :

su - alex
google-authenticator -t -d -f -r 3 -R 30 -w 3

Ces options répondent d'avance aux questions de l'outil : codes basés sur l'heure (-t), chaque code utilisable une seule fois (-d), au plus trois tentatives toutes les 30 secondes (-r 3 -R 30), et une tolérance d'un code avant et après pour absorber un léger décalage d'horloge (-w 3).

Un QR code s'affiche dans le terminal : scannez-le avec votre application. Si le terminal est trop petit, agrandissez la fenêtre ou saisissez manuellement la clé secrète affichée juste en dessous.

⚠️ L'outil affiche aussi cinq codes de secours à usage unique. Copiez-les immédiatement dans votre gestionnaire de mots de passe. Ce sont eux qui vous sauveront si vous perdez votre téléphone.

5. Configurer PAM

Ouvrez /etc/pam.d/sshd. Mettez en commentaire la ligne qui demande le mot de passe du compte, et ajoutez le module TOTP à la place :

# @include common-auth
auth required pam_google_authenticator.so nullok

Commenter common-auth est ce qui évite qu'un mot de passe soit demandé en plus du code. L'option nullok laisse se connecter, avec la clé seule, les comptes qui n'ont pas encore enrôlé de téléphone : pratique pendant la mise en place. Retirez-la quand tous les comptes sont enrôlés.

6. Configurer OpenSSH

Si vous avez suivi notre guide de sécurisation, ouvrez /etc/ssh/sshd_config.d/00-durcissement.conf et modifiez la ligne existante plutôt que d'en ajouter une dans un autre fichier : OpenSSH ne retient que la première valeur qu'il lit.

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

AuthenticationMethods publickey,keyboard-interactive exige les deux étapes, dans cet ordre : la clé d'abord, puis le code. Laissez PasswordAuthentication no en place.

sshd -t && systemctl reload ssh
sshd -T | grep -E "kbdinteractive|authenticationmethods|usepam"

7. Tester sans se bloquer

Depuis un second terminal, en gardant la session actuelle ouverte :

ssh alex@IP_SERVEUR

La clé est vérifiée, puis le serveur affiche Verification code:. Saisissez le code de l'application. Si la connexion échoue :

  • Le code est refusé : vérifiez l'heure du serveur et celle du téléphone.
  • Un mot de passe est demandé : la ligne @include common-auth n'est pas commentée.
  • Aucun code n'est demandé : KbdInteractiveAuthentication est resté à no, vérifiez avec sshd -T.

Les détails de l'échec apparaissent dans journalctl -u ssh -n 30.

8. Codes de secours et exceptions

Chaque code de secours fonctionne une fois, à la place du code de l'application. S'il vous en reste peu, relancez google-authenticator pour générer un nouveau secret et de nouveaux codes ; il faudra alors scanner le nouveau QR code.

Les scripts automatiques, comme une sauvegarde qui se connecte en SSH, ne peuvent pas saisir de code. Exemptez un compte technique précis en fin de fichier /etc/ssh/sshd_config :

Match User borg
    AuthenticationMethods publickey

Limitez ce compte au strict nécessaire, comme décrit dans sauvegardes avec Borg. Et si vous perdez à la fois votre téléphone et vos codes de secours, la console de secours (VNC) de l'espace client, ou à défaut le support, reste le moyen de reprendre la main.

Questions fréquentes

La double authentification SSH est-elle utile si j'utilise déjà une clé ?
Elle protège contre le vol de votre clé : un ordinateur compromis, une sauvegarde non chiffrée ou une clé copiée par erreur. Pour un serveur qui héberge des données clients ou des paiements, c'est une protection raisonnable. Pour un serveur de test, une clé bien protégée suffit généralement.
Que faire si je perds mon téléphone ?
Utilisez l'un des codes de secours affichés lors de l'enrôlement, puis relancez google-authenticator pour enrôler un nouveau téléphone. Sans codes de secours, passez par la console de secours de l'espace client ou par le support.
Faut-il utiliser l'application Google Authenticator ?
Non. Le module du serveur porte ce nom, mais il suit le standard TOTP : toute application compatible fonctionne, y compris Aegis, 2FAS, Microsoft Authenticator ou le module TOTP d'un gestionnaire de mots de passe.
Pourquoi mon code est-il refusé alors qu'il est correct ?
Presque toujours à cause d'un décalage d'horloge entre le serveur et le téléphone. Vérifiez que le serveur est synchronisé avec timedatectl, et que l'heure du téléphone est réglée automatiquement.