Meilleures pratiques pour renforcer la sécurité SSH sur les serveurs Linux

SSH est généralement la première porte que vous ouvrez sur un serveur Linux, donc le durcissement de la sécurité SSH doit avoir lieu avant d'exposer cet hôte à Internet. Les bots tentent constamment des mots de passe faibles, des identifiants réutilisés et des comptes par défaut sur le port 22.

L'objectif est simple : garder l'accès à distance utilisable pour vous et pénible pour les attaquants. Commencez à partir d'une deuxième session de terminal, gardez votre session SSH actuelle ouverte et testez chaque modification avant de redémarrer le démon.

Sauvegardez et testez d'abord la configuration

Avant de modifier /etc/ssh/sshd_config, faites une sauvegarde. Une faute de frappe peut vous verrouiller hors du serveur.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_$(date +%F)

Après modification, vérifiez la syntaxe :

sudo sshd -t

Si le test réussit, rechargez ou redémarrez SSH. Le nom du service est généralement sshd sur les systèmes de type RHEL et ssh sur Debian/Ubuntu :

sudo systemctl restart sshd
# ou
sudo systemctl restart ssh

1. Désactiver la connexion root

La connexion directe root donne à un attaquant le nom d'utilisateur le plus précieux d'emblée. Utilisez un compte utilisateur normal, puis élevez les privilèges avec sudo lorsque vous avez besoin d'un accès administratif.

Étape de configuration

Ouvrez /etc/ssh/sshd_config et localisez la directive PermitRootLogin. Changez sa valeur en no.

# Avant :
# PermitRootLogin yes

# Après (Meilleure pratique) :
PermitRootLogin no

Avant de redémarrer SSH, confirmez que vous pouvez vous connecter en tant qu'utilisateur standard avec les privilèges sudo.

2. Exiger une authentification par clé

L'authentification par mot de passe est facile à attaquer à grande échelle. Les clés SSH sont plus difficiles à deviner, plus faciles à faire pivoter et plus sûres pour l'administration quotidienne lorsque vous protégez la clé privée avec une phrase de passe.

Générer et installer les clés

Générez la paire de clés sur votre machine locale :
```
ssh-keygen -t ed25519 -C "[email protected]"
```

Copiez la clé publique sur le serveur :

ssh-copy-id -i ~/.ssh/id_ed25519 utilisateur@adresse_ip_serveur

Désactiver l'authentification par mot de passe

Une fois que vous avez confirmé que vous pouvez vous connecter avec succès à l'aide de votre clé SSH, désactivez complètement l'authentification par mot de passe.

# Désactiver les mots de passe
PasswordAuthentication no

# Assurez-vous que les clés sont activées
PubkeyAuthentication yes

Ed25519 est une bonne valeur par défaut pour les nouvelles clés. Si vous avez besoin de RSA pour la compatibilité avec des systèmes plus anciens, utilisez une grande clé, par exemple 4096 bits.

3. Envisagez de changer le port SSH par défaut

Changer SSH du port TCP 22 vers un port non standard peut réduire les analyses automatisées bruyantes. Ce n'est pas un remplacement pour les clés, les contrôles d'accès ou la limitation du taux, car n'importe qui peut toujours découvrir le port ouvert avec une analyse.

Étape de configuration

Dans /etc/ssh/sshd_config, modifiez la directive Port :

# Avant :
# Port 22

# Après (Exemple de port non standard) :
Port 22222

Mettez à jour votre pare-feu et tout groupe de sécurité cloud avant de redémarrer SSH. Sinon, votre nouveau démon SSH pourrait écouter sur un port que vous ne pouvez pas atteindre.

Exemple avec firewalld (CentOS/RHEL) :

sudo firewall-cmd --permanent --add-port=22222/tcp
sudo firewall-cmd --reload

4. Limiter l'accès à des utilisateurs et groupes spécifiques

Si seulement un petit ensemble de personnes doit utiliser SSH, spécifiez-le dans sshd_config. Cela bloque les comptes locaux oubliés pour qu'ils ne deviennent pas des points d'entrée à distance.

Directives de configuration

Utilisez l'une ou les deux directives suivantes dans sshd_config :

Autoriser des utilisateurs spécifiques :
```
AllowUsers alice bob
```
Autoriser des groupes spécifiques :
```
AllowGroups sshaccess admins
```

Si ces directives sont présentes, tout utilisateur ou groupe non explicitement listé se verra refuser l'accès.

5. Conserver les valeurs par défaut SSH modernes et désactiver les méthodes héritées

Les versions actuelles d'OpenSSH utilisent déjà le protocole SSH 2 ; la prise en charge de l'ancien protocole 1 a été supprimée d'OpenSSH moderne. Évitez de copier d'anciens extraits de durcissement qui incluent des directives Protocol non prises en charge ou une liste de chiffrements obsolète. Ceux-ci peuvent casser SSH après une mise à niveau.

Concentrez-vous sur la désactivation des mécanismes de confiance hérités, sauf si vous savez que vous en avez besoin :

HostbasedAuthentication no
IgnoreRhosts yes
PermitEmptyPasswords no

Si votre organisation nécessite une politique personnalisée de chiffrement, MAC ou d'échange de clés, vérifiez ce que votre serveur installé prend en charge avant de le modifier :

sshd -T | grep -E '^(ciphers|macs|kexalgorithms) '

Appliquez ensuite uniquement une politique testée qui correspond à votre base de clients. Une liste trop stricte peut verrouiller les anciens hôtes d'automatisation.

6. Ajouter une limitation du taux avec Fail2Ban

Même avec une authentification par clé, les sondes répétées gaspillent des ressources et encombrent les journaux. Fail2Ban surveille les journaux d'authentification et ajoute des bannissements temporaires du pare-feu après des échecs répétés.

Installez Fail2Ban :

# Debian/Ubuntu
sudo apt update && sudo apt install fail2ban

# RHEL/CentOS/Fedora
sudo dnf install fail2ban

Activez la prison sshd. De nombreux systèmes sont livrés avec une configuration par défaut, mais vous devez placer les remplacements locaux dans /etc/fail2ban/jail.local ou un fichier sous /etc/fail2ban/jail.d/.
```
[sshd]
enabled = true
port = 22222
maxretry = 5
bantime = 1h
```
Démarrez le service :
```
sudo systemctl enable --now fail2ban
```

Si vous avez changé le port SSH, faites correspondre la prison Fail2Ban au nouveau port.

7. Ajuster les paramètres de session et d'authentification

Ces paramètres aident à fermer les sessions inactives et à supprimer les chemins d'authentification faibles :

Directive	Valeur recommandée	Objectif
`ClientAliveInterval`	300	Envoie une vérification de maintien de connexion côté serveur toutes les 300 secondes.
`ClientAliveCountMax`	3	Déconnecte après trois vérifications sans réponse.
`UsePAM`	yes	Active les modules d'authentification enfichables (PAM) pour des politiques de sécurité système locales supplémentaires.
`PermitEmptyPasswords`	no	Empêche les comptes avec des mots de passe vides de se connecter.
`MaxAuthTries`	3	Limite les tentatives d'authentification répétées par connexion.
`X11Forwarding`	no	Désactive le transfert X11 sauf si vous l'utilisez réellement.

Liste de contrôle de durcissement

Utilisez cette liste de contrôle pour vous assurer que votre serveur répond aux normes de base de durcissement SSH :

Sauvegardez sshd_config avant d'apporter des modifications.
Définissez PermitRootLogin no.
Définissez PasswordAuthentication no (après la configuration de la clé).
Changez le Port en une valeur non standard.
Mettez à jour le pare-feu pour autoriser le nouveau port.
Utilisez AllowUsers ou AllowGroups pour restreindre l'accès.
Désactivez les méthodes de confiance héritées telles que HostbasedAuthentication.
Installez et configurez Fail2Ban.
Vérifiez la configuration avec sshd -t avant de redémarrer.

Le durcissement de la sécurité SSH fonctionne mieux comme une défense en couches. Les clés empêchent la devinette de mots de passe, les restrictions d'utilisateurs réduisent qui peut se connecter, les règles de pare-feu limitent d'où viennent les connexions et Fail2Ban ralentit les sondes répétées. Gardez une session de travail ouverte pendant que vous testez, puis documentez le nouveau port et la méthode de connexion pour quiconque exploite le serveur.