SSH sécurisé : configurer les clés, limiter les accès et désactiver les authentifications risquées

Ouvrez les journaux d’un serveur Linux exposé sur Internet : en quelques minutes, des dizaines de tentatives de connexion SSH avec « root », « admin » ou « ubuntu » défilent. Ces robots testent des mots de passe en permanence. Un serveur SSH bien configuré les rend totalement inoffensifs. Voici la configuration de référence, étape par étape, avec les précautions pour ne pas vous enfermer dehors.

L’essentiel en 30 secondes

• Authentification par clé uniquement (Ed25519, idéalement sur clé matérielle FIDO2), mots de passe désactivés.
• Connexion root interdite, accès réservé à un groupe d’utilisateurs nommés.
• Accès SSH limité par adresse IP, VPN ou bastion plutôt qu’ouvert à tout Internet.
• OpenSSH à jour : les versions récentes ont corrigé des failles graves et adoptent par défaut des algorithmes résistants aux ordinateurs quantiques.
• Toujours tester la configuration (sshd -t) et garder une session ouverte avant de recharger le service.

Étape 1 : créer de bonnes clés

Sur votre poste, générez une clé Ed25519 protégée par une phrase de passe :

ssh-keygen -t ed25519 -a 100 -C "prenom.nom@poste-admin"

Encore mieux, avec une clé de sécurité matérielle (YubiKey, Token2, SoloKey) : la clé privée ne quitte jamais le composant, et une présence physique est exigée à chaque connexion.

ssh-keygen -t ed25519-sk -O resident -O verify-required -C "prenom.nom-fido2"

Copiez ensuite la clé publique sur le serveur :

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

Abandonnez les anciennes clés RSA de 1024 ou 2048 bits et les clés DSA, que les versions récentes d’OpenSSH ne prennent d’ailleurs plus en charge.

Étape 2 : la configuration du serveur

Plutôt que de modifier le fichier principal, créez un fichier dédié, par exemple /etc/ssh/sshd_config.d/10-durcissement.conf (pris en compte par les distributions récentes) :

# Authentification
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no

# Qui peut se connecter
AllowGroups ssh-admins

# Limiter les abus
MaxAuthTries 3
LoginGraceTime 30
MaxStartups 10:30:60

# Fonctions inutiles
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

# Sessions inactives
ClientAliveInterval 300
ClientAliveCountMax 2

Créez le groupe et ajoutez-y les administrateurs :

sudo groupadd ssh-admins
sudo usermod -aG ssh-admins prenom

Réactivez AllowTcpForwarding uniquement si vous utilisez des tunnels SSH, et seulement pour les comptes qui en ont besoin (bloc Match User).

Étape 3 : appliquer sans se bloquer dehors

1. Vérifiez la syntaxe : sudo sshd -t (aucun message signifie aucune erreur).
2. Gardez votre session actuelle ouverte.
3. Rechargez le service : sudo systemctl reload ssh (ou sshd selon la distribution).
4. Ouvrez une nouvelle connexion depuis un autre terminal pour confirmer que tout fonctionne.
5. Vérifiez que la connexion par mot de passe est refusée : ssh -o PubkeyAuthentication=no prenom@serveur.

Prévoyez toujours un accès de secours : console de l’hébergeur, accès physique, console de l’hyperviseur.

Étape 4 : réduire l’exposition

Étape 5 : maîtriser les clés autorisées

• Restreignez les clés dans ~/.ssh/authorized_keys avec des options : from="203.0.113.10",restrict ssh-ed25519 AAAA... pour une clé utilisée par un script.
• Faites une revue trimestrielle des clés présentes : une clé d’ancien prestataire oubliée est un accès permanent. Voir notre procédure de départ d’un salarié.
• Pour plusieurs administrateurs et serveurs, envisagez les certificats SSH signés par une autorité interne, avec une durée de validité courte : plus besoin de distribuer les clés sur chaque serveur.

Étape 6 : maintenir et contrôler

• Gardez OpenSSH à jour avec les mises à jour de la distribution. La faille « regreSSHion » (CVE-2024-6387), corrigée en juillet 2024, permettait une exécution de code à distance sur des serveurs non mis à jour. Depuis la version 10.0 (avril 2025), OpenSSH utilise par défaut un échange de clés hybride résistant aux ordinateurs quantiques.
• Auditez la configuration avec l’outil open source ssh-audit, qui signale les algorithmes faibles encore acceptés.
• Surveillez les connexions réussies dans les journaux (journalctl -u ssh) et alertez sur les connexions depuis des adresses inhabituelles. Voir nos commandes Linux de diagnostic.

Questions fréquentes

Changer le port 22 suffit-il ?

Non. Cela réduit le nombre de tentatives automatiques dans les journaux, mais un scanner retrouve le port en quelques secondes. C’est un confort, pas une protection.

Faut-il une phrase de passe sur la clé privée ?

Oui, sauf pour les clés de scripts automatisés, qui doivent alors être restreintes (adresse source, commande autorisée). Un agent SSH évite de la saisir à chaque connexion.

Comment se connecter depuis Windows ?

Le client OpenSSH est intégré à Windows 10 et 11 : la commande ssh et ssh-keygen s’utilisent dans PowerShell ou le Terminal Windows, y compris avec des clés FIDO2.

Et si je perds ma clé ?

Prévoyez au moins deux clés enregistrées (par exemple une clé matérielle de secours rangée en lieu sûr) et un accès console de secours.

Sources

• OpenSSH, notes de version.
• ANSSI, recommandations pour un usage sécurisé d’OpenSSH.
• NVD, CVE-2024-6387 (regreSSHion).
• ssh-audit.

Besoin d’un accompagnement ?

MPCÂBLE Solutions Informatiques (MPCSI) accompagne particuliers, entreprises, associations et collectivités depuis Gaudiès, en Ariège : sur site en Occitanie, principalement dans un rayon de 40 km (Pamiers, Foix, Mirepoix, Saverdun, Castelnaudary), et à distance partout en France. Nous sécurisons et supervisons vos serveurs Linux dans le cadre de notre infogérance. Demandez un devis gratuit ou appelez le 05 32 42 99 98.