Bienvenue dans ce tutoriel consacré à SSH.

Vous avez un serveur Linux (peut être sur un VPS, ou un Raspberry Pi, ou encore sur une machine à la maison) et vous vous y connectez en SSH pour y accéder à distance. Ce tutoriel vous montre comment rendre cet accès plus solide, en suivant les bonnes pratiques actuelles en sécurité.

Accrochez-vous tout de même, cela nécessite de mettre les mains dans le cambouis.

Pourquoi durcir SSH ?

SSH (pour Secure SHell) constitue une porte d'entrée de votre serveur. N'importe quel personne qui la franchit, avec les bons droits, peut tout lire, tout modifier, tout effacer ! Et cette porte est bien souvent très sollicitée étant donné les risques. Un serveur exposé sur Internet reçoit donc des tentatives de connexion automatiques en permanence et très vite après la configuration SSH. Des bots tentent des couples identifiant + mot de passe à la chaîne.

Mais il y a bien sûr une façon de réduire drastiquement les risques, grâce aux bonnes pratiques et recommandations (nous faisons ici références bien souvent aux publications par l'ANSSI, le BSI allemand, le NCSC britannique, le CIS et le projet OpenSSH lui-même).

Ce que ce tutoriel couvre

  • Mettre OpenSSH à jour.
  • Remplacer le mot de passe par une clé.
  • Fermer l'accès direct au compte root et limiter les comptes autorisés.
  • Vérifier que tout fonctionne, puis surveiller les journaux.

En revanche, nous ne traiterons pas ici des certificats SSH, des profils cryptographiques gouvernementaux ni des listes d'algorithmes à figer à la main. Ces réglages servent aux professionnels de l'infrastructure, et ils font plus de dégâts qu'autre chose quand on les copie sans les maîtriser. Nous resterons donc sur un socle de base grand public.

Pré-requis

  • Un serveur sous Debian ou Ubuntu, avec compte personnel et droits sudo.
  • Un ordinateur (Linux, macOS ou Windows) d'où vous vous connectez.
  • Une seconde voie d'accès au serveur : la console web de votre hébergeur par exemple (type Infomaniak ou Hostinger), un écran et un clavier branchés dessus, etc. ou bien un second terminal SSH.
🚨
Ce dernier point n'est pas négociable. Si une erreur de configuration vous ferme la porte SSH, c'est la seule façon de rentrer et de réparer les dégâts.

Repérez-la maintenant, avant de toucher à quoi que ce soit.

Étape 1 : mettre à jour OpenSSH

Cela peut surprendre, mais c'est la mesure la plus importante de tout ce tutoriel. Les failles graves de ces dernières années touchaient le programme lui-même, et seule une mise à jour les corrigeait.

Sur le serveur, lancez :

sudo apt update
sudo apt upgrade

Puis vérifiez bien ensuite la version installée :

ssh -V
💡
Important : le numéro de version d'OpenSSH sur votre serveur est peut-être plus ancien que celui affiché sur le site du projet openSSH. C'est normal bien souvent : Ubuntu et Debian appliquent eux-mêmes les correctifs de sécurité à leur version.

Tant que vous installez les mises à jour du système, votre OpenSSH est à jour. Inutile (et même déconseillé) de l'installer vous-même, i.e. de le compiler.

A l'écriture de ce tutoriel : en octobre 2026, on trouve par exemple :
Distribution Version d'OpenSSH
Ubuntu 24.04 LTS 9.6p1
Ubuntu 26.04 LTS 10.2p1
Debian 13 « trixie » 10.0p1

Côté chiffrement, même chose : les versions récentes d'OpenSSH protègent déjà vos échanges contre les futurs risques post-quantiques, sans aucun réglage. Ne touchez pas aux réglages d'algorithmes

Étape 2 : créer et installer votre clé SSH

Une clé SSH fonctionne comme une paire de clés asymétriques : vous déposez la clé publique sur le serveur, et vous gardez au chaud la clé privée sur votre ordinateur distant. Seul celui qui détient la clé privée peut ouvrir, c'est tout l'intérêt d'utiliser les clés SSH.

Nous vous invitons à relire notre article dédié sur le chiffrement afin de revoir les bases côté asymétrique :

Le Chiffrement
Article traitant des notions de chiffrement dans son ensemble et les outils recommandés.
Wikilibristeayo

Générer la clé

Sur votre ordinateur (pas sur le serveur), ouvrez un terminal et tapez :

ssh-keygen -t ed25519

Petites explications :

  • -t ed25519 choisit le type de clé recommandé aujourd'hui : court, rapide et solide.
    ▶️ Et non : les clés RSA ne sont plus vraiment recommandées, même si l'algorithme RSA reste robuste, mais uniquement pour des clés au-delà de 3072 ou 4096 bits. Cela dit, une clé ed25519 sera plus simple à utiliser.
  • Acceptez le dossier/fichier proposé avec la touche Entrée (ou sélectionnez votre chemin si vous savez ce que vous faites).
  • Choisissez ensuite une phrase secrète...
⚠️
Important : il est possible de ne rien entrer dans ce champ phrase secrète (i.e. phrase secrète vide), cela rend l'utilisation SSH par clés plus simple ! Néanmoins, il est fortement recommandé d'ajouter une phrase secrète (ou un mot de passe) pour les clés SSH.

En effet si quelqu'un venait à copier votre clé privée (vol d'ordinateur, retrait d'une sauvegarde, etc.), la phrase secrète empêchera de s'en servir. Si elle n'est pas protégée, celui qui aura récupéré la clé privée pourra se connecter à votre serveur.

Cette phrase secrète peut très bien être générée par un gestionnaire de mots de passe, et y être stockée aussi, cela vous permettra de la retrouver plus facilement.

Ensuite, ne copiez jamais votre clé privée sur une autre machine, laissez la où elle est.

Vous obtenez deux fichiers dans le dossier ~/.ssh/ et si vous avez accepté les entrées par défaut :

  • id_ed25519 (clé privée, à garder pour vous)
  • id_ed25519.pub (clé publique, à envoyer au serveur).

Envoyer la clé publique au serveur

Toujours depuis votre ordinateur :

ssh-copy-id <votre_utilisateur>@<adresse_du_serveur>

Remplacez <votre_utilisateur> par votre nom de compte sur le serveur, et <adresse_du_serveur> par son adresse IP. La commande vous demande votre mot de passe une dernière fois, puis ajoute la clé publique au fichier ~/.ssh/authorized_keys du serveur.

Vérifier les permissions

SSH refuse une clé si les droits d'accès sur les fichiers qui la contiennent sont trop permissifs. Sur le serveur, connecté avec votre compte, entrez ceci :

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

La première ligne réserve le dossier à vous seul, la seconde fait de même pour le fichier des clés autorisées.

Étape 3 : tester avant de toucher à la configuration

La règle d'or de ce tutoriel : gardez une session ouverte (ouverte via mot de passe qui est nous imaginons déjà en place) le temps de la configuration.

  1. Gardez votre session SSH actuelle ouverte, et ne la fermez pas avant la fin de la configuration.
  2. Ouvrez un second terminal et connectez-vous au serveur.
ssh <votre_utilisateur>@<adresse_du_serveur>

Le serveur doit vous demander la phrase secrète de votre clé (ou rien, si un agent SSH la garde en mémoire), et non plus votre mot de passe de compte serveur.

🟢 Si c'est bien le cas, la clé fonctionne. Bravo !
❌ Sinon, revenez à l'étape 2 avant d'aller plus loin.

Vérifiez au passage que sudo fonctionne avec ce compte, puisque nous allons fermer l'accès direct à root. Faites donc sur le serveur :

sudo -v

Étape 4 : appliquer la configuration durcie

Sur Debian et Ubuntu, le fichier principal /etc/ssh/sshd_config charge d'abord tous les fichiers .conf du dossier /etc/ssh/sshd_config.d/, par ordre alphabétique. Et pour chaque réglage, c'est la première valeur lue qui gagne.

Ce détail a l'air anodin, mais il a toute son importance : sur beaucoup de serveurs cloud, l'outil cloud-init dépose un fichier 50-cloud-init.conf dans /etc/ssh/sshd_config.d/ , qui contient PasswordAuthentication yes et qui risque d'entrer en conflit avec notre authentification par clés.

Si nous regardons de plus près, par exemple :

ls /etc/ssh/sshd_config.d/
grep -ri passwordauthentication /etc/ssh/sshd_config.d/

Nous obtenons dans ces cas là quelque chose comme :

50-cloud-init.conf
grep: /etc/ssh/sshd_config.d/50-cloud-init.conf: Permission denied
💡
Attention : ceci ne vaut principalement que pour les VPS. Sur des instances que vous auto-hébergez vous-même, les distros n'ajoutent rien dans le dossier /etc/ssh/sshd_config.d/.

Quoiqu'il arrive, nous allons donc créer notre propre fichier, avec un nom qui commence par 10- , pour qu'il soit lu en premier dans tous les cas :

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

Le bloc de configuration

Le bloc suivant constitue le socle de base du durcissement de la configuration. Collez simplement ces instructions dans le fichier 10-durcissement.conf, en remplaçant <votre_utilisateur> par votre vrai nom de compte sur le serveur (sans les chevrons!) :

# Authentification : clé uniquement
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
PermitRootLogin no

# Qui peut se connecter, et combien d'essais
AllowUsers <votre_utilisateur>
MaxAuthTries 3
LoginGraceTime 60

# Sessions inactives
ClientAliveInterval 300
ClientAliveCountMax 3

# Fonctions inutiles
X11Forwarding no

# Journaux plus détaillés
LogLevel VERBOSE
⚠️
Vérifiez deux fois l'orthographe du nom dans AllowUsers. Une faute de frappe, et plus personne ne peut se connecter.

Enregistrez (Ctrl+O puis Entrée) et quittez (Ctrl+X).

Explications sur ces directives

Voici les justifications pour ceux qui veulent comprendre le côté technique :

  • PubkeyAuthentication yes : autorise la connexion par clé.
  • PasswordAuthentication no et KbdInteractiveAuthentication no : ferment strictement les deux façons de taper un mot de passe. Les robots qui essaient des mots de passe n'ont plus rien à essayer.
  • PermitEmptyPasswords no : interdit les comptes sans mot de passe (c'est déjà le défaut, mais on le rajoute de nouveau pour être ultra clair).
  • PermitRootLogin no : interdit toute connexion directe en root. Vous vous connectez avec votre compte utilisateur, puis pour devenir admin, vous utilisez sudo. C'est pour cela que nous avons vérifié sudo à l'étape 3.
  • AllowUsers <votre_utilisateur> : seul ce compte peut se connecter en SSH. Pour en autoriser plusieurs, séparez les noms par des espaces (et non des virgules).
  • MaxAuthTries 3 : vous avez un nombre maximum de 3 essais par connexion au lieu de 6 par défaut. Au delà vous serez bloqué.
  • LoginGraceTime 60 : 1 minute pour s'authentifier au lieu de 2. Ce qui réduit les risques.
  • ClientAliveInterval 300 et ClientAliveCountMax 3 : ici, le serveur vérifie toutes les 5 minutes que votre ordinateur répond, et coupe après 3 vérifications sans réponse. Les deux lignes vont ensemble comme vous le remarquez.
  • X11Forwarding no : désactive l'affichage d'applications graphiques à distance, dont vous n'avez sûrement pas l'usage, et qui introduisent des risques inutiles.
  • LogLevel VERBOSE : c'est la seule ligne qui pourrait se discuter. Peut-être que vous ne souhaitez pas des journaux trop verbeux, dans ce cas il conviendra de modifier à WARNING. Les journaux notent l'empreinte de la clé utilisée à chaque connexion. Pratique pour savoir qui s'est connecté avec quoi.

Tester, recharger, retester

D'abord, faites vérifier la syntaxe par OpenSSH lui-même :

sudo sshd -t

Si la commande n'affiche rien, tout va bien. Si elle affiche une erreur, corrigez le fichier avant d'aller plus loin.

Ensuite, vérifiez la configuration réellement appliquée, comme suit :

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers'

Vous devez lire passwordauthentication no, permitrootlogin no et votre nom d'utilisateur. Si passwordauthentication vaut encore yes, un autre fichier passe avant le vôtre : retournez voir le contenu de /etc/ssh/sshd_config.d/.

Puis rechargez le service SSH :

sudo systemctl reload ssh

Enfin, sans fermer votre première session, ouvrez encore un autre terminal et reconnectez-vous. Pour vérifier que les mots de passe sont bien refusés, vous pouvez forcer une tentative sans clé comme ceci :

ssh -o PubkeyAuthentication=no <votre_utilisateur>@<adresse_du_serveur>

La réponse attendue est un refus, du style Permission denied (publickey).

Si tout est bon, bravo, votre serveur n'accepte plus que votre clé !

Étape 5 : vérifier et surveiller

Consultez de temps en temps les journaux du service SSH :

sudo journalctl -u ssh --since today

Grâce à LogLevel VERBOSE, vous pourrez y voir les connexions réussies avec l'empreinte de la clé utilisée, et les tentatives refusées. Ne vous affolez pas devant les dizaines d'essais venus d'adresses inconnues sur un serveur exposé : c'est le bruit de fond d'Internet, mais désormais vous êtes protégés.

Pour aller plus loin

Limiter les tentatives répétées

Ici, nous avons 2 approches qui existent, et toutes 2 sont tout à fait valables :

  • PerSourcePenalties : qui est une directive intégrée à OpenSSH directement, depuis la version 9.8. Cette directive pénalise voire bloque les adresses qui multiplient les échecs à la connexion SSH.
  • fail2ban : il s'agit d'un outil tiers, et est plus ancien et plus configurable que le premier point. Il permet de bannir temporairement les adresses qui multiplient les échecs.
    ▶️ Attention, si vous l'utilisez, ajoutez votre propre adresse dans son paramètre ignoreip, pour ne pas vous bannir vous-même 😄
Nous n'avons pas ici de recommandation préférée. Certains préféreront fail2ban car c'est un outil robuste, connu des spécialistes. Et parfois le PerSourcePenalties sera préféré (cela dit, certaines distros anciennes ne le proposent pas).

La double authentification

Oui, il est possible aussi sur SSH d'exiger, en plus de la clé SSH, un code à usage unique. C'est utile sur des accès sensibles, mais la mise en place passe par PAM (le module d'authentification de Linux), et une erreur de réglage peut rouvrir discrètement l'authentification par mot de passe...

Nous préférons donc la réserver pour les profils qui savent vérifier ce point.

Et le port 22 ?

Il s'agit du conseil le plus répandu, et aussi le plus discuté.

L'ANSSI le recommande pour un serveur exposé à un réseau non maîtrisé, par exemple internet.

Le CIS, le NIST, le BSI et Mozilla, eux, ne le comptent pas parmi les mesures de sécurité. Pourquoi ? parce que les attaquants de toute façon scannent aussi tous les autres ports, et leurs bots tend à se perfectionner avec le temps. Il n'est donc plus nécessaire de passer son temps à re-configurer le port 22.

Concrètement, changer de port réduit surtout le bruit dans vos journaux. C'est optionnel et non prioritaire selon nous. Si vous le faites malgré tout, ouvrez d'abord le nouveau port dans votre pare-feu, sinon vous vous enfermez tout seul !

Autres pièges ?

Dernier point pour ceux qui fouillent les vieux tutoriels sur la toile (et il y en a beaucoup) : n'ajoutez surtout pas la directive Protocol 2 (obsolète depuis longtemps) ni même LoginGraceTime 0 (déprecié).

Ce dernier réglage a été proposé comme parade temporaire à regreSSHion. Depuis le correctif, la bonne pratique est de mettre à jour et de garder un délai court, comme nous le proposons plus haut (60 secondes).

Pour aller plus loin

Les sources sur lesquelles s'appuie les bonnes pratiques :

Contributeur(s) : Ayo