A
Objectif
Durcir l’accès SSH sur un bastion Linux sans casser l’accès de secours. Ce runbook démontre le kit ops de lecture DailyOps: code copiable, checklist interactive, callouts et tableaux.
Matrice de décision rapide
| Situation | Action | Priorité |
|---|---|---|
| Serveur exposé Internet | Clés only + fail2ban | P1 |
| Bastion interne | Clés only, MFA jump | P2 |
| Lab / éphémère | Durcissement minimal documenté | P3 |
Checklist interactive
Coche au fil de l’eau (état local navigateur, rien n’est envoyé au serveur):
- Inventaire des comptes avec shell
- Clés SSH déployées pour les admins
PasswordAuthentication notesté sur une 2e session- fail2ban ou équivalent actif
- Procédure break-glass documentée
Configuration de référence
bash
# /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers opsadmin jumpuser
Après édition:
bash
sshd -t && systemctl reload sshd
Tableau des contrôles
| Contrôle | Où vérifier | OK si |
|---|---|---|
| Auth par clé | sshd -T | grep passwordauthentication | no |
| Root login | sshd -T | grep permitrootlogin | no ou prohibit-password |
| Bannière | /etc/issue.net | Message légal présent |
Pièges fréquents
- Couper le mot de passe avant d’avoir déployé les clés.
- Oublier les comptes de service avec shell.
- Appliquer un template CIS sans fenêtre de rollback.
Fin de runbook
Quand la checklist est verte, archive la date, l’opérateur, et le hash de la config dans le ticket de change. Le prochain article relie ce type de contenu au reste de la base DailyOps (liens, notes, CTA).