Sécurise ton SSH : des clés, zéro mot de passe, zéro stress

Tu viens de monter un nouveau serveur Linux (un VPS, une VM Proxmox, un Raspberry Pi), SSH est activé, tu t'y connectes avec ton mot de passe, ça marche, affaire classée. Sauf que si ton serveur est exposé sur internet, il se fait scanner en continu par des bots qui tentent des milliers de combinaisons login/mot de passe toutes les heures. Ce n'est pas de la parano, c'est juste la réalité de tout ce qui a une IP publique.

Dans cet article, on va voir comment y remédier : générer des clés SSH, supprimer l'authentification par mot de passe, et installer fail2ban pour bannir automatiquement les bots. Quelques minutes de config pour te protéger efficacement de ce type d'attaque.

Prérequis

• Un serveur Linux avec SSH installé (OpenSSH)
• Un accès root ou sudo sur ce serveur
• Un terminal sur ta machine cliente (Linux, macOS, ou Windows avec WSL/PowerShell)

Étape 1 - Générer une paire de clés SSH

Le principe est simple : tu génères une paire de clés (publique + privée). La clé publique va sur le serveur, la clé privée reste sur ta machine. Sans la clé privée, impossible de se connecter, peu importe le mot de passe.

Choisir l'algorithme : ed25519 ou RSA ?

ed25519 est le choix recommandé aujourd'hui : clés courtes, sécurité excellente, plus rapide que RSA. Utilise RSA 4096 uniquement si tu dois t'interfacer avec un vieux système qui ne supporte pas ed25519.

# Génération ed25519 (recommandé)
ssh-keygen -t ed25519 -C "guillaume@domopi"

# Alternative RSA 4096
ssh-keygen -t rsa -b 4096 -C "guillaume@domopi"

Le -C c'est juste un commentaire pour t'y retrouver, mets ce que tu veux.

Lors de la génération, on te demande :

• L'emplacement : accepte le défaut (~/.ssh/id_ed25519) ou donne un nom spécifique si tu gères plusieurs clés.
• Une passphrase : je te conseille fortement d'en mettre une. Elle protège ta clé privée si quelqu'un accède à ta machine.

En résultat, on obtient deux fichiers dans ~/.ssh/ :

• id_ed25519 → ta clé privée (ne la partage jamais et ne la copie pas n'importe où)
• id_ed25519.pub → ta clé publique (celle qui va sur les serveurs auxquels tu voudras te connecter)

Copier la clé publique sur le serveur

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@adresse-serveur

Si ssh-copy-id n'est pas disponible (notamment sur Windows PowerShell), la version manuelle :

cat ~/.ssh/id_ed25519.pub | ssh user@adresse-serveur "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Teste la connexion par clé avant de continuer :

ssh -i ~/.ssh/id_ed25519 user@adresse-serveur

Si ça marche sans mot de passe (ou juste avec la passphrase de ta clé), on peut passer à la suite.

SSH est strict sur les permissions des fichiers. Si elles sont trop ouvertes, il refuse de fonctionner. Voici les valeurs correctes à appliquer côté client :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config          # si tu utilises un fichier de config

Et côté serveur, sur le fichier qui contient tes clés autorisées :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Connexion avec PuTTY sous Windows

PuTTY utilise son propre format de clé (.ppk). Il faut d'abord convertir ta clé avec PuTTYgen :

1. Ouvre PuTTYgen → Load → sélectionne ta clé id_ed25519 (affiche "All files" pour la voir)
2. Save private key → enregistre le fichier .ppk

Ensuite dans PuTTY :

• Hostname : user@adresse-serveur
• Connection > SSH > Auth > Credentials : charge ton fichier .ppk
• Open pour te connecter

Étape 2 - Désactiver l'authentification par mot de passe

C'est ici que les bots deviennent complètement inutiles. Avec l'authentification par mot de passe désactivée, leurs tentatives de brute force ne servent strictement à rien.

Édite le fichier de configuration SSH :

sudo nano /etc/ssh/sshd_config

Trouve (ou ajoute) ces lignes :

# Désactiver l'authentification par mot de passe
PasswordAuthentication no

# Désactiver l'authentification keyboard-interactive (couverture complète)
KbdInteractiveAuthentication no

# Désactiver le login root direct
PermitRootLogin no

Recharge le service sans fermer ta session actuelle :

sudo systemctl reload sshd

Ouvre un nouveau terminal et teste que tu peux toujours te connecter par clé. Si c'est bon, tu peux fermer l'ancienne session.

Étape 3 - Fail2ban : bannir les insistants

Même avec l'authentification par mot de passe désactivée, des tentatives de connexion vont continuer. Fail2ban surveille les logs et bloque automatiquement les IPs qui accumulent trop d'échecs. C'est utile pour deux raisons : ça réduit le bruit dans les logs, et ça protège si un autre vecteur d'authentification venait à être activé par erreur plus tard.

sudo apt install fail2ban -y

Crée un fichier de config local (ne pas modifier jail.conf directement, il sera écrasé lors des mises à jour) :

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
# Adapte à ton réseau local
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24

[sshd]
enabled = true
port    = ssh # soit le port 22 par défaut
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Active et démarre le service :

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Quelques commandes utiles au quotidien :

# Voir les IPs bannies
sudo fail2ban-client status sshd

# Débannir une IP (si tu t'es fait ban toi-même...)
sudo fail2ban-client set sshd unbanip 1.2.3.4

# Suivre les logs en direct
sudo tail -f /var/log/fail2ban.log

Bonus

Gérer plusieurs serveurs avec ~/.ssh/config

Quand tu commences à avoir un homelab un peu conséquent, avoir des alias propres pour chaque machine évite les erreurs bêtes du genre se connecter au mauvais serveur. Le fichier ~/.ssh/config est là pour ça :

Host monserveur
    HostName 192.168.1.50
    User guillaume
    IdentityFile ~/.ssh/id_ed25519

Avec ça, la commande ssh monserveur suffit, au lieu de taper ssh -i ~/.ssh/id_ed25519 guillaume@192.168.1.50 à chaque fois.

Une bonne pratique complémentaire : utilise une clé différente par contexte (usage perso, usage pro, accès critique). Si une clé est compromise, l'impact reste limité.

Ne taper la passphrase qu'une seule fois avec ssh-add

Si tu as mis une passphrase sur ta clé (ce que je recommande), pense à ssh-add pour ne la taper qu'une seule fois par session :

ssh-add ~/.ssh/id_ed25519

Sous Windows, tu peux également utiliser pageant, disponible sur le site de PuTTY.

Conclusion

Cette configuration, je l'applique systématiquement sur toutes mes nouvelles machines (VPS, VMs Proxmox ...). Clés ed25519, configuration d'OpenSSH renforcée et fail2ban : c'est le socle indispensable pour tout ce qui a une IP publique.

Et toi, tu gères tes accès SSH comment ? Des configs particulières ou des outils que tu utilises ? Partage en commentaires ou viens en discuter sur le groupe Telegram DomoPi.