Sécuriser OpenSSH sur Ubuntu

Introduction

OpenSSH est le serveur SSH par défaut sur Ubuntu, Debian, CentOS, FreeBSD et plein d’autres systèmes Linux. C’est souvent installé de base.

C’est crucial de bien le sécuriser, car c’est la porte d’entrée principale pour accéder à ton serveur. Ici, j’explique comment renforcer ce serveur OpenSSH avec différentes options de configuration pour que l’accès à distance soit aussi sûr que possible.

Étape 1 : Le renforcement général

On va commencer par une configuration de base solide qui marche pour la plupart des serveurs. Si tu as des besoins très spécifiques ou un modèle de menace particulier, tu pourras aller plus loin, mais ça dépasse le cadre de ce guide.

On va travailler ici sur le fichier de config standard : /etc/ssh/sshd_config, donc avant toute chose :

Sauvegarde ta config de base

Avant de toucher à quoi que ce soit, on fait toujours une sauvegarde.

$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.old

Maintenant, on a une copie de secours. Si on casse un truc on peut facilement revenir à la configuration d’origine avec

$ sudo cp /etc/ssh/sshd_config.old /etc/ssh/sshd_config

Modifier et tester les paramètres

Se connecter en parallèle Avant de faire des changements, ouvre une deuxième session SSH sur le serveur. Comme ça, si tu te plantes et que tu perds l’accès, tu pourras corriger depuis la session qui est restée ouverte. ssh user@<SERVER IP> Maintenant, tu as deux sessions ouvertes : une pour faire les changements, et une autre pour tester et corriger si besoin.

Pour voir les options actuelles et valider ton fichier, lance le serveur en mode test étendu. Ça t’affiche la config effective :

$ sudo sshd -T

Maintenant, ouvre le fichier avec ton éditeur préféré (vim, nano, etc.) :

$ sudo vim /etc/ssh/sshd_config

Tu verras que certaines options sont commentées avec un #. Pour les activer ou changer leur valeur, enlève le #.

La base de la sécu (Recommandé)

Première chose : interdire le login en root. C’est la base.

PermitRootLogin no

Ensuite, limite le nombre d’essais de mot de passe pour éviter le brute-force :

MaxAuthTries 3

Tu peux aussi réduire le temps qu’a un utilisateur pour s’authentifier (la “grace period”) :

LoginGraceTime 20

Passer aux clés SSH (Recommandé)

Les clés SSH, c’est bien plus sûr que les mots de passe. pour plus d’informations sur les clés et le protocole SSH, renseigne-toi ici.

Si tu n’as pas encore de paire de clés, génères-en une (tuto ici).

Ensuite, envoie ta clé publique sur le serveur depuis ton ordi :

ssh-copy-id user@<SERVER IP>

Une fois que tes clés marchent, désactive l’authentification par mot de passe. Comme ça, même si un mot de passe fuite, personne ne rentre.

PasswordAuthentication no

Pour être sûr, refuse les mots de passe vides (même si PasswordAuthentication est à no, c’est une bonne pratique) :

PermitEmptyPasswords no

Désactiver ce qui ne sert pas (Recommandé)

Par défaut, SSH active plein de méthodes d’auth dont tu n’as probablement pas besoin. Désactive-les pour réduire la surface d’attaque :

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

Le déport d’affichage (X11 Forwarding) sert à lancer des applis graphiques à distance. Si c’est un serveur sans écran, t’en as pas besoin :

X11Forwarding no

Pareil pour les variables d’environnement utilisateur, ça peut être risqué :

PermitUserEnvironment no

Si tu ne fais pas de tunneling ou de redirection de port, coupe tout ça :

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

Enfin, cache la bannière SSH qui donne trop d’infos sur ton OS (version Debian/Ubuntu, etc.) :

DebianBanner no

Valider et appliquer

Sauvegarde et quitte ton éditeur. Avant de recharger le service, vérifie que t’as pas fait de faute de frappe :

$ sudo sshd -t

Si ça ne dit rien, c’est que c’est bon. S’il y a une erreur, corrige-la.

Ensuite, recharge la config :

$ sudo service sshd reload

Étape 2 : White list d’IP (Optionnel)

Tu peux restreindre l’accès à certaines adresses IP seulement. C’est radical mais efficace. Dans le cadre d’une infra personnelle, ça peut notamment permettre de configurer un “bastion” pour accéder a tes serveurs depuis une IP fixe, ou un VPN.

Pour connaître ton IP actuelle (celle qui est connectée au serveur) :

$ w

Ça te sortira un truc du genre :

Output
14:11:48 up 2 days, 12:25, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
ton_user pts/0 203.0.113.1 12:24 1.00s 0.20s 0.00s w

Ici, ton IP c’est 203.0.113.1 (exemple).

Ouvre à nouveau ta config :

$ sudo nvim /etc/ssh/sshd_config

Utilise AllowUsers pour filtrer qui peut se connecter et d’où. Choisis ce qui correspond à ton besoin :

Juste une IP précise pour tout le monde :

AllowUsers *@203.0.113.1

Une plage d’IP (subnet) :

AllowUsers *@203.0.113.0/24

Plusieurs IPs :

AllowUsers *@203.0.113.1 *@203.0.113.2

Des utilisateurs spécifiques depuis des IPs spécifiques :

AllowUsers sammy@203.0.113.1 alex@203.0.113.2

Combiner avec Match pour être plus fin (ex: restreindre toto à une IP, mais laisser les autres tranquilles) :

Match User toto
AllowUsers toto@203.0.113.1

⚠️ Attention : Les blocs Match s’appliquent jusqu’à la fin du fichier ou jusqu’au prochain Match. Mets-les toujours à la fin de ton fichier pour ne pas appliquer leurs règles à tout le monde par erreur.

Vérifie et applique :

$ sudo sshd -t
$ sudo service sshd reload

Étape 3 : Restreindre le shell (Avancé)

Parfois, tu veux donner un accès pour transférer des fichiers (SFTP) mais pas pour lancer des commandes shell.

Bloquer le shell interactif

Tu peux utiliser /usr/sbin/nologin comme shell pour un utilisateur.

Créer un utilisateur restreint :

$ sudo adduser --shell /usr/sbin/nologin alex

Ou modifier un existant :

$ sudo usermod --shell /usr/sbin/nologin sammy

Si cet utilisateur essaie de se connecter en SSH classique, il se fera jeter poliement.

SFTP uniquement (Chroot)

Pour vraiment verrouiller un utilisateur dans un dossier (Chroot) et ne lui laisser que le SFTP :

Ouvre /etc/ssh/sshd_config.

On va utiliser ForceCommand internal-sftp et ChrootDirectory.

Ajoute ça à la fin du fichier :

Match User alex
ForceCommand internal-sftp
ChrootDirectory /home/alex/

Ça force l’utilisation du serveur SFTP interne et enferme alex dans son dossier /home/alex/. Il ne pourra rien voir d’autre sur le serveur.

Toujours pareil, vérifie et applique :

$ sudo sshd -t
$ sudo service sshd reload

Voilà, alex est maintenant en “prison” SFTP : pas de shell, et impossible de sortir de son dossier.

Conclusion

Nous avons couvert les principales étapes pour durcir OpenSSH, porte d’entrée principale pour accéder à son serveur. En désactivant ce qui ne sert pas, en passant aux clés SSH et en limitant les accès, on a considérablement réduit les risques d’intrusion.

Si tu veux aller encore plus loin dans la sécurisation du protocole SSH, jette un œil au manuel de sshd_config.

Sinon, tu peux aussi envisager d’ajouter des couches de sécurité supplémentaires disponibles dans les autres articles du site !