Sécuriser l'accès SSH d'un serveur Linux

Un serveur exposé en SSH reçoit en permanence des tentatives de connexion automatisées qui essaient des milliers de couples identifiant/mot de passe. La parade la plus efficace : n'accepter que les clés SSH, et interdire la connexion directe en root.

Ce tutoriel suit un ordre précis pour ne jamais vous couper l'accès : on installe et teste la clé avant de désactiver les mots de passe.

1. Créer une paire de clés sur votre poste

Sur votre ordinateur (pas sur le serveur) :

ssh-keygen -t ed25519 -C "spo@poste-bureau"

• Acceptez l'emplacement proposé (~/.ssh/id_ed25519).
• Choisissez une phrase de passe : elle protège la clé si votre poste est volé. L'agent SSH la retiendra pour la session.

Deux fichiers sont créés :

2. Installer la clé publique sur le serveur

Linux et macOS :

ssh-copy-id admin@192.168.1.50

Windows (PowerShell), où ssh-copy-id n'existe pas :

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh admin@192.168.1.50 "umask 077; mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Remplacez admin par votre utilisateur et l'adresse par celle du serveur.

3. Tester la connexion par clé

ssh admin@192.168.1.50

La connexion doit aboutir sans demander le mot de passe du compte (seulement la phrase de passe de la clé, si vous en avez mis une).

4. Durcir la configuration du serveur

Plutôt que de modifier le fichier principal /etc/ssh/sshd_config, créez un fichier dédié dans /etc/ssh/sshd_config.d/. Il survit aux mises à jour du paquet et se repère facilement.

sudo nano /etc/ssh/sshd_config.d/00-durcissement.conf

Contenu :

# Authentification par clé uniquement
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# Pas de connexion directe en root : on se connecte puis on utilise sudo
PermitRootLogin no

# Limiter les essais et le délai de connexion
MaxAuthTries 3
LoginGraceTime 30

# Fonctions inutiles sur un serveur
X11Forwarding no

# Seuls ces comptes peuvent se connecter (séparés par des espaces)
AllowUsers admin

5. Vérifier puis appliquer, sans fermer la session

Vérifiez la syntaxe. La commande ne doit rien afficher :

sudo sshd -t

Vérifiez la configuration réellement appliquée :

sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|allowusers)'

Résultat attendu :

permitrootlogin no
passwordauthentication no
kbdinteractiveauthentication no
allowusers admin

Rechargez le service :

sudo systemctl reload ssh       # Debian, Ubuntu
sudo systemctl reload sshd      # Fedora, RHEL, Rocky, Alma, Arch

6. Contrôler que les mots de passe sont bien refusés

Depuis votre poste, forcez une tentative par mot de passe :

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password admin@192.168.1.50

Réponse attendue : Permission denied (publickey). Le serveur ne propose même plus le mot de passe.

Aller plus loin

• Pare-feu : n'autorisez le port 22 que depuis vos réseaux d'administration ou votre VPN. C'est plus efficace que toute autre mesure.
• Fail2ban ou CrowdSec : bannissent temporairement les adresses qui multiplient les échecs. Utiles sur un serveur exposé à Internet, moins indispensables une fois les mots de passe désactivés.
• Changer de port : réduit le bruit dans les journaux, mais n'apporte pas de sécurité réelle. Sous Ubuntu 22.10 et suivantes, SSH peut être démarré par ssh.socket : le port se change alors dans la configuration du socket, pas seulement dans sshd_config.
• Journaux : sudo journalctl -u ssh --since today (ou -u sshd) montre les connexions et les échecs.

En cas de problème