SSH sécurisé sans mot de passe : le guide complet pour une configuration SSH robuste

Un mot de passe SSH sécurisé, aussi long soit-il, reste une cible pour le brute-force. Il suffit de regarder les logs auth.log d’un serveur exposé sur Internet quelques heures pour comprendre l’ampleur du problème : des milliers de tentatives de connexion automatisées, jour et nuit, sur le port 22.

La solution éprouvée par les administrateurs systèmes depuis des décennies consiste à remplacer l’authentification par mot de passe par une paire de clés cryptographiques. Ce guide détaille la configuration SSH complète, de la génération des clés avec ssh-keygen jusqu’au durcissement du serveur, avec les commandes exactes à exécuter et les pièges à éviter.

Pourquoi abandonner l’authentification par mot de passe

L’authentification par clé repose sur la cryptographie asymétrique : une clé privée, qui ne quitte jamais votre machine, et une clé publique, déposée sur chaque serveur auquel vous voulez accéder. Le serveur chiffre un défi avec la clé publique, et seule la clé privée correspondante permet d’y répondre. À aucun moment un secret ne transite sur le réseau.

Les avantages concrets :

La limite à connaître : si la clé privée n’est pas protégée par une passphrase et qu’elle est compromise (poste volé, disque mal effacé), l’accès au serveur l’est aussi. C’est pourquoi la passphrase et la gestion rigoureuse des clés restent indispensables, même dans ce modèle.

Voici un schéma simple qui récapitule les différentes étapes pour se connecter en SSH sans mot de passe avec l’utilisation des clés SSH :

Prérequis

Génération de la paire de clés avec ssh-keygen

Sur votre poste client, exécutez :

ssh-keygen -t ed25519 -C "votre_email@exemple.com"

Pourquoi Ed25519 plutôt que RSA

ssh-keygen propose plusieurs algorithmes : RSA, ECDSA, Ed25519. Pour une configuration SSH moderne, Ed25519 est le choix recommandé :

RSA reste pertinent uniquement si vous devez supporter d’anciens équipements (certains firmwares réseau, vieux appliances) qui ne connaissent pas encore Ed25519. Dans tous les autres cas, Ed25519 s’impose : clés plus courtes, calculs plus rapides, et aucune faiblesse cryptographique documentée à ce jour.

Le choix de l’emplacement et de la passphrase

La commande vous pose deux questions :

Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):

Deux fichiers sont créés : id_ed25519 (privée, ne jamais la partager) et id_ed25519.pub (publique, celle que vous allez déployer).

Déployer la clé publique sur le serveur

Méthode recommandée : ssh-copy-id

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

Cette commande se connecte au serveur avec les identifiants existants (mot de passe ou clé), ajoute votre clé publique dans ~/.ssh/authorized_keys côté serveur, et applique les bonnes permissions automatiquement.

Méthode manuelle

Si ssh-copy-id n’est pas disponible (Windows sans WSL, par exemple) :

cat ~/.ssh/id_ed25519.pub | ssh utilisateur@serveur "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Les permissions comptent réellement ici. OpenSSH refuse silencieusement un authorized_keys trop ouvert :

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

Vérifier l’accès SSH sécurisé avant de couper le mot de passe

Ne désactivez jamais l’authentification par mot de passe avant d’avoir confirmé que la connexion par clé fonctionne. Ouvrez un nouveau terminal, sans fermer votre session en cours, et testez :

ssh -i ~/.ssh/id_ed25519 utilisateur@serveur

Si la connexion s’établit sans demander de mot de passe (seulement la passphrase de la clé, le cas échéant), vous pouvez passer à l’étape de durcissement. En cas d’échec, ajoutez -v (voire -vvv) à la commande pour obtenir les logs détaillés côté client.

Durcir la configuration SSH côté serveur

Une fois l’accès par clé validé, éditez /etc/ssh/sshd_config :

sudo nano /etc/ssh/sshd_config

Appliquez ces paramètres :

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no

Redémarrez le service :

sudo systemctl restart sshd

Avant de fermer votre session actuelle, ouvrez un nouveau terminal et validez qu’une connexion par clé fonctionne toujours. C’est l’erreur la plus fréquente et la plus coûteuse : redémarrer sshd avec une mauvaise configuration et perdre l’accès au serveur, surtout sans accès KVM ou console de secours.

Aller plus loin : changer le port et limiter les tentatives

Deux mesures complémentaires, non indispensables mais utiles sur un serveur exposé publiquement :

Port 2222
MaxAuthTries 3

Changer le port par défaut (22) ne bloque pas un attaquant déterminé, mais réduit drastiquement le bruit des scans automatiques dans vos logs. Couplez cela avec fail2ban pour bannir automatiquement les IP après plusieurs échecs :

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Automatiser les connexions avec ssh-agent

Pour éviter de ressaisir la passphrase à chaque connexion tout en gardant la clé privée chiffrée sur le disque, utilisez ssh-agent :

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Sous Linux avec un environnement de bureau, ssh-agent peut être lancé automatiquement à l’ouverture de session via gnome-keyring ou keychain. Sur macOS, ajoutez à ~/.ssh/config:

Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_ed25519

Le fichier ~/.ssh/config mérite d’ailleurs d’être systématisé si vous gérez plusieurs serveurs : il permet d’associer une clé, un utilisateur et un port différents à chaque alias, sans avoir à s’en souvenir.

Host prod
  HostName 203.0.113.10
  User deploy
  Port 2222
  IdentityFile ~/.ssh/id_ed25519_prod

Une simple commande ssh prod suffit ensuite.

Bonnes pratiques de gestion des clés SSH

Dépannage courant

« Permission denied (publickey) » : vérifiez les permissions de ~/.ssh (700) et authorized_keys (600) côté serveur, ainsi que le propriétaire des fichiers (chown -R utilisateur:utilisateur ~/.ssh).

La connexion redemande un mot de passe malgré la clé configurée : confirmez que PubkeyAuthentication yes est bien actif dans sshd_config, et que la clé publique déployée correspond bien à la clé privée utilisée côté client (ssh -v affiche la clé essayée).

Verrouillage après modification de sshd_config : si l’accès SSH est coupé, seule une console physique ou KVM (souvent fournie par l’hébergeur) permet de corriger le fichier et de redémarrer le service.

FAQ : SSH sécurisé sans mot de passe

Est-il vraiment plus sûr de désactiver l’authentification par mot de passe ? Oui, à condition que vos clés privées soient protégées par une passphrase et stockées sur des postes de confiance. Un mot de passe SSH peut être deviné ou intercepté ; une clé Ed25519 ou RSA 4096 bits ne se casse pas par force brute dans un délai réaliste.

Puis-je utiliser la même clé SSH sur plusieurs serveurs ? Techniquement oui, la même clé publique peut être déposée sur autant de serveurs que nécessaire. Pour limiter l’impact d’une compromission, une clé distincte par contexte (perso, pro, automatisation) reste préférable.

Que se passe-t-il si je perds ma clé privée ? Vous perdez l’accès aux serveurs qui n’acceptent que cette clé. D’où l’importance d’en garder une sauvegarde chiffrée, et de toujours conserver un accès de secours (autre clé, console physique) avant de désactiver totalement les mots de passe.

RSA ou Ed25519, lequel choisir avec ssh-keygen ? Ed25519 pour toute nouvelle configuration : clés plus courtes, calculs plus rapides, sécurité au moins équivalente. RSA reste utile uniquement pour la compatibilité avec de vieux équipements qui ne supportent pas encore Ed25519.

Faut-il mettre une passphrase sur la clé privée ? Sur un poste de travail, oui, systématiquement. Elle protège la clé en cas de vol ou de compromission du disque. Seules certaines automatisations très encadrées (compte de service isolé, droits restreints) justifient une clé sans passphrase.

Comment se connecter en SSH sans mot de passe depuis Windows ? PowerShell moderne embarque un client OpenSSH natif : les commandes ssh-keygen, ssh-copy-id (via WSL ou manuellement) et ssh fonctionnent de la même manière que sous Linux ou macOS.

PermitRootLogin no empêche-t-il toute administration en root ? Non. Il interdit uniquement la connexion SSH directe avec le compte root. La pratique recommandée consiste à se connecter avec un utilisateur standard puis à utiliser sudo pour les opérations nécessitant les droits root, ce qui améliore aussi la traçabilité des actions.

ssh-agent est-il indispensable ? Non, mais il évite de ressaisir la passphrase à chaque connexion sans pour autant stocker la clé privée en clair sur le disque. Particulièrement utile si vous vous connectez fréquemment à plusieurs serveurs dans une même session de travail.

Comment automatiser un déploiement SSH sans stocker de mot de passe en clair ? En générant une clé SSH dédiée à ce compte de service, avec des droits restreints côté serveur (utilisateur limité, authorized_keys avec des options command= ou restrict si seule une commande précise doit être exécutable), plutôt qu’en intégrant un mot de passe dans le script.

Un changement de port SSH suffit-il à sécuriser un serveur ? Non. Cela réduit le bruit des scans automatisés dans les logs, mais ne remplace ni l’authentification par clé ni un pare-feu correctement configuré. C’est une mesure complémentaire, pas une protection en soi.

Conclusion

Passer à une configuration SSH sans mot de passe demande une vingtaine de minutes une fois la méthode connue : génération de la paire de clés avec ssh-keygen, déploiement de la clé publique, vérification de l’accès, puis durcissement de sshd_config. Le gain en sécurité et en confort d’usage est immédiat, en particulier dès que plusieurs serveurs ou des tâches automatisées entrent en jeu.

Si vous administrez plusieurs machines, l’étape suivante logique consiste à centraliser la gestion des clés et la configuration sshd avec un outil comme Ansible, plutôt que de répéter ces manipulations serveur par serveur.