SSH hardening Linux : AllowUsers, sshd et 2FA

À la fin de ce tutoriel ssh hardening, vous saurez durcir le serveur OpenSSH : drop-in sshd_config.d, PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes, AllowUsers / AllowGroups, MaxAuthTries / LoginGraceTime, valider avec sshd -t avant reload, et ajouter un lab 2FA PAM (libpam-google-authenticator) avec codes de secours — console / SSM obligatoires avant toute coupure. Ce n’est pas un redo de SSH & clés (ssh-keygen / ssh-copy-id).

Niveau : Intermédiaire+ · Temps estimé : 50–60 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-11

Slug proposé : linux-ssh-hardening · Série : Linux Réseau & Sécurité · Remplace / fusionne : N/A — création (chapitre 4, fin lot 1)

Prérequis

• Hub Linux Réseau & Sécurité ; TLS certbot utile (même discipline « ne pas se lock-out »)
• P5 SSH & clés : connexion par clé déjà OK pour votre user lab — on ne refait pas la génération de clé
• Console provider, IPMI ou SSM ouverte avant d’éditer sshd / PAM
• Seconde session SSH déjà authentifiée (filet) ; sudo ; pas de secrets dans le dépôt
• User lab non-root présent dans AllowUsers (ex. devops)

Coût : 0 €. Risque maximal de la série : sshd/PAM mal configurés = plus d’accès réseau. Snapshot VM + console = non négociable.

Ce que nous allons construire

Rappel : client P5 vs serveur sshd (ce tuto)
  → Drop-in sshd_config.d · sshd -t · reload
  → PermitRootLogin / PasswordAuthentication / PubkeyAuthentication
  → AllowUsers · MaxAuthTries · LoginGraceTime
  → Lab 2FA : google-authenticator + PAM · codes secours
  → Rollback / nettoyage

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « SSH hardening : AllowUsers, sshd_config.d, 2FA PAM, console de recovery ».)

Dernier chapitre lot 1 Sécurité. Le client (clés, agent) = Basics ; ici la politique d’écoute du démon sshd. Enchaînez avec nft + fail2ban déjà en place : réduire qui parle à :22, puis qui a le droit de s’authentifier, puis avec quel second facteur.

Avant toute écriture : console de recovery ouverte. Ne coupez pas mots de passe et activez 2FA et restreignez AllowUsers dans le même geste sans plan de rollback.

Étape 1 — Client P5 vs serveur : où agir

Couche	Tuto	Exemples
Client	SSH & clés	ssh-keygen, authorized_keys, ~/.ssh/config
Serveur	Ce chapitre	/etc/ssh/sshd_config, PAM, 2FA
Réseau	nft / fail2ban	Qui atteint le port 22

# Qui écoute ? (rappel)
ss -tlnp | grep -E ':22|:2222' || true
# Conf active (lecture)
sudo sshd -T 2>/dev/null | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|maxauthtries|logingracetime' | sort
# Sessions : gardez-en une ouverte
who; echo "USER_LAB=$USER"

Étape 2 — Drop-in sshd_config.d et sshd -t

N’écrasez pas tout sshd_config : ajoutez un drop-in (Ubuntu/Debian : Include /etc/ssh/sshd_config.d/*.conf).

# Backup timestampé
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d)
sudo mkdir -p /etc/ssh/sshd_config.d

# Remplacez devops par VOTRE user lab (celui qui a déjà une clé)
sudo tee /etc/ssh/sshd_config.d/99-lab-hardening.conf >/dev/null << 'EOF'
# Lab ssh hardening — VM jetable
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowUsers devops
MaxAuthTries 3
LoginGraceTime 45
# Optionnels lab :
# AllowGroups sshusers
# PermitEmptyPasswords no
# X11Forwarding no
EOF

# Adapter le user réellement connecté
sudo sed -i "s/^AllowUsers .*/AllowUsers $USER/" /etc/ssh/sshd_config.d/99-lab-hardening.conf
grep AllowUsers /etc/ssh/sshd_config.d/99-lab-hardening.conf

# TOUJOURS tester avant reload
sudo sshd -t && echo "sshd -t OK"
sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

Directive	Effet
PermitRootLogin no	Pas de root direct via SSH
PasswordAuthentication no	Clés (ou 2FA) — plus de mdp SSH
PubkeyAuthentication yes	Auth par clé activée
AllowUsers	Liste blanche de comptes
MaxAuthTries	Tentatives par connexion
LoginGraceTime	Délai avant coupure si non auth

Rocky/Alma : service souvent sshd ; mêmes directives. Vérifiez qu’aucun fichier sshd_config.d plus prioritaire ne ré-autorise les mots de passe. Astuce : après reload, sshd -T est la vérité effective — plus fiable que relire les fichiers à la main.

Test depuis un autre terminal (gardez l’ancien ouvert) :

# Depuis le client : doit réussir avec la clé existante (P5)
# ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no $USER@lab
# Échec attendu pour un user hors AllowUsers
sudo sshd -T | grep -i allowusers

Étape 3 — Lab 2FA : libpam-google-authenticator + PAM

La 2FA ajoute un TOTP après (ou avec) la clé. Console obligatoire avant d’activer PAM.

sudo apt install -y libpam-google-authenticator
# En tant que USER lab (pas root) — interactif : répondez y aux prompts raisonnables
# google-authenticator
# → scannez le QR avec une app TOTP ; NOTEZ les codes de secours (hors Git)

# Non interactif minimal pour automatiser un lab (moins pédagogique) :
google-authenticator -t -d -f -r 3 -R 30 -w 3 -q || 
  echo "Lancez 'google-authenticator' en interactif dans votre session user"
ls -la ~/.google_authenticator 2>/dev/null || echo "Fichier secret TOTP absent — terminer l’enrôlement avant PAM"

Drop-in PAM + sshd pour exiger clé et code (lab) :

# Backup PAM sshd
sudo cp -a /etc/pam.d/sshd /etc/pam.d/sshd.bak.$(date +%Y%m%d)

# Ajouter l’auth TOTP (Ubuntu/Debian courants)
if ! grep -q 'pam_google_authenticator.so' /etc/pam.d/sshd; then
  sudo sed -i '/^@include common-auth/i auth required pam_google_authenticator.so nullok' /etc/pam.d/sshd
fi
# nullok = laisse passer si pas encore enrôlé — RETIREZ nullok quand tout le monde a un secret

# sshd : challenge PAM / kbd interactive pour le TOTP
sudo tee /etc/ssh/sshd_config.d/99-lab-2fa.conf >/dev/null << 'EOF'
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
# Sur anciennes versions : ChallengeResponseAuthentication yes
EOF

sudo sshd -t && sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd
echo "2FA lab armé — testez UNE nouvelle session ; gardez console + vieille session"

Élément	Rôle
~/.google_authenticator	Secret TOTP user (mode 400)
Codes de secours	Recovery si téléphone perdu — coffre, pas chat
AuthenticationMethods publickey,keyboard-interactive	Clé puis TOTP
nullok	Transition ; à retirer en durcissement final

Client de test : ssh user@lab → succès clé → prompt verification code. Si échec : console, commentez la ligne PAM / supprimez 99-lab-2fa.conf, sshd -t, reload.

Étape 4 — Vérifications et rollback

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|allowusers|authenticationmethods|pubkeyauthentication'
sudo systemctl is-active ssh sshd 2>/dev/null
# journal auth (échec / succès)
sudo journalctl -u ssh -u sshd -n 30 --no-pager 2>/dev/null || sudo journalctl -n 30 --no-pager | grep -i ssh | tail

# Rollback 2FA (console)
# sudo mv /etc/pam.d/sshd.bak.* /etc/pam.d/sshd   # ou retirer la ligne pam_google_authenticator
# sudo rm -f /etc/ssh/sshd_config.d/99-lab-2fa.conf
# sudo sshd -t && sudo systemctl reload ssh || sudo systemctl reload sshd

# Rollback hardening AllowUsers (si vous vous êtes exclus)
# sudo rm -f /etc/ssh/sshd_config.d/99-lab-hardening.conf
# sudo sshd -t && sudo systemctl reload ssh || sudo systemctl reload sshd

Étape 5 — Nettoyage lab (fin lot 1)

# Sur VM jetable : retirer drop-ins lab OU les conserver documentés
# sudo rm -f /etc/ssh/sshd_config.d/99-lab-hardening.conf
# sudo rm -f /etc/ssh/sshd_config.d/99-lab-2fa.conf
# Restaurer PAM si besoin :
# sudo cp -a /etc/pam.d/sshd.bak.* /etc/pam.d/sshd
# sudo sshd -t && sudo systemctl reload ssh || sudo systemctl reload sshd
# Optionnel : rm -f ~/.google_authenticator  (révoque TOTP lab)
echo "Fin lot1 Sécurité — hub : /tutoriels/linux-reseau-securite/"

Validé si : sshd -T montre root/mdp refusés, AllowUsers = votre compte, nouvelle session clé OK, 2FA lab testé ou rollback 2FA maîtrisé, console jamais fermée trop tôt.

Erreurs fréquentes

Symptôme	Cause	Correction
Lock-out total	AllowUsers sans votre compte / PAM cassé	Console ; supprimer drop-in ; restaurer PAM
sshd -t error	Typo directive	Corriger avant reload — ne jamais reload si -t fail
MDP encore accepté	Autre fichier conf ré-autorise	sshd -T ; chercher PasswordAuthentication
2FA bloque tout le monde	nullok retiré trop tôt / pas d’enrôlement	Console ; PAM ; ré-enrôler
Clé OK mais 2FA ignore	AuthenticationMethods / KbdInteractive off	Drop-in 2FA + reload
Redo inutile ssh-keygen	Confusion client/serveur	Clés = P5 ; ici = sshd
Codes secours perdus	Pas de coffre	Régénérer via console + google-authenticator

Quiz (3 questions)

1. Pourquoi sshd -t avant reload ?
– A. Pour accélérer SSH
– B. Pour valider la syntaxe / directives et éviter un démon cassé (lock-out)
– C. Pour générer une clé

2. Rôle de AllowUsers ?
– A. Bannir des IP (fail2ban)
– B. Restreindre quels comptes locaux peuvent se connecter en SSH
– C. Remplacer authorized_keys

3. Que faire avant d’activer PAM 2FA ?
– A. Rien de spécial
– B. Ouvrir console/SSM, session SSH filet, codes de secours notés, plan de rollback PAM
– C. Supprimer toutes les clés

Réponses : 1‑B · 2‑B · 3‑B

FAQ

Faut-il regénérer une clé pour ce tuto ?
Non si P5 est fait et que authorized_keys fonctionne. Le ssh hardening porte sur sshd et PAM, pas sur ssh-keygen.

AllowUsers ou AllowGroups ?
AllowUsers : liste courte explicite (lab / petits VPS). AllowGroups : équipe (sshusers). Évitez les deux vides + restrictifs contradictoires.

2FA remplace-t-elle fail2ban ?
Non. 2FA protège le compte ; fail2ban / nft limitent le bruit réseau. Les trois se complètent (fail2ban, nftables).

Pour aller plus loin

• man sshd_config, man pam_google_authenticator
• Fin lot 1 : retour hub Linux Réseau & Sécurité · suite menu Linux Shell & Automation
• Prérequis client : SSH & clés · secours SSM

Maillage série Linux Réseau & Sécurité

← Précédent	TLS avec certbot : HTTPS nginx et Caddy
→ Suivant	Hub Linux Réseau & Sécurité (fin lot 1) · Shell & Automation
Hub	Linux Réseau & Sécurité
Prérequis P5	SSH & clés

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : SSH hardening : AllowUsers, sshd et 2FA (2026)
• Meta description (≤ 155) : Durcissez sshd (AllowUsers, clés only) et ajoutez 2FA PAM en lab. Suite SSH clés Basics — DevOps 2026.
• Focus keyphrase : ssh hardening
• KW secondaires : AllowUsers, sshd_config, google-authenticator, 2FA SSH
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-ssh-hardening-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Intermédiaire+
• Slug : linux-ssh-hardening
• Statut : HOLD — draft only (ne pas publier)