Hardening SSH avec Ansible : ma méthode pour sécuriser un serveur Linux sans me couper l’accès

Réponse rapide

Pour faire du hardening ssh ansible proprement, je procède toujours dans le même ordre : je vérifie qu’un utilisateur d’administration existe, que sa clé SSH fonctionne, que sudo marche, je sauvegarde la configuration actuelle, je modifie sshd_config, je valide avec sshd -t, puis je recharge le service et je teste une nouvelle session avant de couper définitivement les méthodes risquées comme l’authentification par mot de passe.

Pourquoi durcir SSH est la première brique de sécurité

SSH reste la porte d’entrée standard pour administrer un serveur Linux. Tant que cet accès est mal protégé, le reste du hardening perd une partie de sa valeur. Je vois régulièrement des serveurs exposés avec PasswordAuthentication yes, un compte root encore autorisé à se connecter directement, ou des clés SSH mal distribuées. Dans ce contexte, un simple bruteforce, une fuite de mot de passe ou une mauvaise habitude d’exploitation suffit pour transformer un accès d’admin en point de compromission.

Je préfère donc séparer les sujets. Ici, je me concentre uniquement sur SSH : l’authentification, le compte root, les clés, la validation de configuration et l’ordre de déploiement. Le firewall, Fail2ban et le hardening système global méritent leur propre traitement. Cette séparation est utile autant pour le SEO que pour la pratique : on garde un article lisible et un plan d’action concret.

Ce que je vérifie avant toute modification

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sshd -t

Cette étape a l’air basique, mais c’est là que se joue la différence entre une opération propre et un incident d’exploitation. Le hardening SSH n’est pas compliqué techniquement. Il devient dangereux quand il est fait trop vite, sans filet de sécurité et sans séquencement.

Ma méthode manuelle pas à pas

Quand je dois sécuriser un serveur Linux manuellement, je procède toujours en deux temps. D’abord je m’assure que l’accès sain existe. Ensuite seulement je coupe les accès risqués.

1. Vérifier ou créer l’utilisateur admin

sudo adduser linux-man
sudo usermod -aG sudo linux-man

Le but est d’éviter toute dépendance au compte root pour l’administration quotidienne. Un compte nominatif, avec sudo, est plus traçable et plus simple à gérer dans le temps.

2. Installer la clé publique

sudo mkdir -p /home/linux-man/.ssh
echo "ssh-ed25519 AAAA... votre-cle-publique" | sudo tee /home/linux-man/.ssh/authorized_keys > /dev/null
sudo chmod 700 /home/linux-man/.ssh
sudo chmod 600 /home/linux-man/.ssh/authorized_keys
sudo chown -R linux-man:linux-man /home/linux-man/.ssh

À ce stade, j’ouvre une seconde session SSH pour vérifier que la connexion par clé fonctionne réellement. Tant que ce test n’est pas concluant, je ne touche pas à l’authentification par mot de passe.

3. Modifier la configuration SSH

Selon les distributions, le fichier principal reste /etc/ssh/sshd_config. Je garde une conf lisible, sans accumulation de vieilles directives commentées dans tous les sens.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

Je ne change pas systématiquement le port SSH. Ce réglage peut réduire le bruit des scans les plus simples, mais il ne remplace jamais une authentification propre par clé, ni une politique d’accès cohérente.

4. Valider avant reload

sudo sshd -t
sudo systemctl reload ssh
# ou selon la distribution
sudo systemctl reload sshd

Le test de syntaxe est non négociable. Un reload avec une mauvaise configuration peut casser l’accès immédiatement. Ensuite, je teste une nouvelle session depuis un autre terminal. Si ça passe, je considère le changement validé.

Les directives SSH que je veux vraiment comprendre

Tu remarqueras que je ne transforme pas cet article en guide de hardening global. Je ne détaille pas UFW ici, parce que l’objectif est vraiment de rendre SSH propre, compréhensible et déployable sans risque. Pour le firewall, je traiterais ça à part.

Pourquoi je passe ensuite à Ansible

Faire ce travail à la main est utile une fois, parce que ça force à comprendre ce qu’on change. En revanche, sur plusieurs serveurs, ce n’est pas tenable. Tu t’exposes vite à des écarts de configuration, des oublis, des validations faites trop vite, ou des déploiements non reproductibles. C’est exactement là qu’Ansible devient intéressant.

Avec un rôle, je peux standardiser les directives, garder mes variables lisibles, versionner les choix de sécurité et rejouer le même durcissement de façon cohérente. Ça ne remplace pas la compréhension manuelle, ça l’industrialise.

Exemple de playbook avec le rôle et détail des variables

Le repo babidi34/ansible-role-secure-os me sert justement à industrialiser cette logique. L’idée n’est pas de cacher la complexité sous le tapis, mais de transformer une méthode fiable en déploiement reproductible.

---
- name: Harden SSH on Debian servers
  hosts: debian_servers
  become: true
  roles:
    - role: secure-os
      vars:
        ssh_allow_users:
          - linux-man
        ssh_passwordauthentication: "no"
        ssh_permit_root_login: "no"
        ssh_max_auth_tries: 3
        ssh_login_grace_time: "30"
        use_fail2ban: true
        authorized_ports_tcp:
          - 22
          - 443

Ce que j’aime dans cette approche, c’est qu’on voit immédiatement les choix de sécurité appliqués.

Dans ce rôle, les variables SSH principales exposées par défaut sont notamment ssh_allow_users, ssh_passwordauthentication, ssh_permit_root_login, ssh_max_auth_tries, ssh_login_grace_time, use_fail2ban et authorized_ports_tcp. J’ai repris ici les vraies variables du rôle pour que l’exemple soit directement cohérent avec le repo.

Un bon rôle Ansible ne doit pas t’éviter de réfléchir. Il doit t’éviter de refaire à la main, de façon inconstante, des choix que tu as déjà validés techniquement.

FAQ

Conclusion

Le plus important dans le hardening SSH avec Ansible n’est pas la sophistication de la configuration. C’est la méthode. Si tu comprends d’abord la logique manuelle, les garde-fous et l’ordre d’application, tu peux ensuite automatiser sans transformer chaque déploiement en roulette russe. C’est exactement comme ça que je vois le rôle : non pas comme une boîte noire, mais comme une manière fiable de reproduire une procédure saine.