Dans un environnement où un mot de passe finit souvent par s’user, la clé SSH reste une méthode plus nette, plus robuste et bien plus agréable au quotidien sur Linux. En quelques gestes, il devient possible d’obtenir un accès sécurisé à un serveur Linux sans ressaisir ses identifiants à chaque session, tout en gardant la main sur la clé privée, la clé publique et les réglages de sécurité indispensables.
L’article en bref
La connexion SSH par clé remplace le mot de passe par une authentification plus fiable, à condition de bien préparer le client et le serveur. Le principe est simple, mais quelques règles évitent les mauvaises surprises.
- Paire de clés bien séparée : La clé privée reste locale, la clé publique va sur le serveur
- Génération propre sous Linux : Ed25519 offre un bon équilibre entre simplicité et sécurité
- Déploiement côté serveur : authorized_keys doit contenir la bonne clé publique
- Accès sécurisé confirmé : testez avant de couper le mot de passe
Avec une configuration SSH soignée, l’accès devient plus fluide sans sacrifier la sécurité.
Voici la ligne directrice la plus saine pour un serveur Linux : générer une clé SSH sur la machine cliente, l’installer dans le bon compte distant, vérifier que la connexion fonctionne, puis seulement ensuite désactiver l’authentification par mot de passe. C’est exactement le genre de méthode qui évite les interventions d’urgence à minuit, lorsque l’on découvre qu’un accès administratif a disparu après un changement trop rapide. Un fil conducteur simple aide à garder le cap : l’utilisateur conserve sa clé privée, le serveur ne reçoit que la clé publique, et la configuration SSH reste lisible, même plusieurs mois plus tard.
Dans la pratique, la mécanique repose sur la cryptographie asymétrique : la clé publique sert à reconnaître l’identité, la clé privée sert à la prouver. La première peut circuler sans risque, la seconde doit rester protégée, idéalement par une phrase secrète. Sur une machine bien tenue, ce duo donne un accès sécurisé beaucoup plus résistant aux attaques par essai de mots de passe, surtout quand les services exposés sont visibles depuis Internet.
SSH by key Linux : comprendre l’authentification par clé avant la configuration
Une session SSH classique commence souvent par un mot de passe, ce qui reste pratique mais rarement idéal sur la durée. Avec l’authentification par clé, le serveur Linux vérifie plutôt une preuve cryptographique que l’utilisateur détient bien la clé privée correspondante, ce qui change nettement le niveau de sécurité sans alourdir l’usage au quotidien.
Sur le terrain, ce fonctionnement ressemble un peu à une serrure à double contrôle : la clé publique est déposée dans authorized_keys sur le serveur, tandis que la clé privée ne quitte jamais le poste client. Si cette clé privée est protégée par une passphrase, un vol matériel ne suffit plus à ouvrir les portes immédiatement, ce qui laisse un vrai temps d’avance pour révoquer l’accès.
Ce que fait réellement le serveur lors d’une connexion SSH
Lors de la connexion, le client SSH propose une identité et le serveur vérifie si la clé publique associée est autorisée. Si elle l’est, le client démontre qu’il possède bien la clé privée sans l’envoyer sur le réseau, ce qui préserve l’accès sécurisé tout en limitant l’exposition des secrets.
Un point mérite d’être retenu : une ligne commentée dans /etc/ssh/sshd_config ne désactive rien. Le comportement effectif peut être contrôlé avec sshd -T, une vérification utile quand plusieurs distributions Linux affichent des réglages semblables mais appliquent en réalité des paramètres par défaut.
Pourquoi la clé SSH rassure davantage qu’un mot de passe
Un mot de passe se devine, se réutilise ou se brise par automatisation. Une clé SSH bien générée, elle, ne s’exporte pas facilement et ne traverse pas le réseau, ce qui réduit d’un cran les scénarios d’attaque les plus courants.
Dans un atelier de bricolage numérique, cette logique rappelle la différence entre un plan affiché au mur et la clé du local : le plan peut être partagé, mais la clé reste dans la poche. L’image est parlante, et la sécurité aussi.
Préparer le serveur Linux et le poste client pour une configuration SSH propre
Avant de générer quoi que ce soit, quelques vérifications évitent les blocages les plus banals. Le serveur Linux doit disposer de openssh-server, le client de openssh-client, et le port 22 doit être autorisé par le pare-feu lorsque rien n’a été déplacé vers un autre numéro.
Sur Debian comme sur AlmaLinux, les connexions par mot de passe et par clés sont souvent actives par défaut. Pour connaître l’état réel, mieux vaut ne pas se fier aux lignes commentées de la configuration SSH et interroger directement le démon, ce qui révèle sans ambiguïté les valeurs appliquées.
| Élément à vérifier | Rôle dans la connexion SSH | Point d’attention |
|---|---|---|
| openssh-server | Fait tourner le service SSH sur le serveur Linux | Doit être installé et actif |
| openssh-client | Permet les connexions depuis le poste local | Indispensable pour ssh, ssh-keygen, ssh-copy-id |
| Port 22 | Autorise le trafic SSH entrant | À ouvrir dans le pare-feu si nécessaire |
| sshd_config | Contient les paramètres de configuration SSH | Les lignes commentées ne changent rien |
Les vérifications qui évitent de perdre l’accès
Une habitude simple fait gagner du temps : confirmer que le service SSH répond avant toute modification. Ensuite, tester la connexion depuis une autre fenêtre de terminal permet de garder une porte de secours ouverte pendant la mise en place de la clé SSH.
Cette prudence rappelle la première maquette montée trop vite, avec trop de colle : le résultat semblait bon sur le moment, puis les pièces ont glissé. En administration système, l’excès de confiance produit parfois le même effet, avec des conséquences plus longues à réparer.
Créer une clé SSH ed25519 sur Linux avec ssh-keygen
Pour une configuration SSH moderne, ed25519 offre un excellent compromis entre sobriété et robustesse. La commande ssh-keygen permet de créer une paire de clés, avec une clé privée et une clé publique, en choisissant un nom de fichier clair et un commentaire lisible pour l’identifier plus tard.
L’option -t définit le type de clé, -f fixe le chemin de sortie et -C ajoute une étiquette utile, par exemple pour distinguer un poste de travail, un portable ou un serveur d’appoint. Si aucune phrase secrète n’est saisie, l’option -N « » permet d’indiquer explicitement une phrase vide, mais la plupart des usages gagnent à conserver une protection.
Ce que contient le dossier .ssh après génération
Une fois la commande exécutée, le répertoire ~/.ssh apparaît automatiquement s’il n’existait pas encore. La clé privée y est enregistrée avec des droits stricts, tandis que la clé publique peut être lue plus librement, ce qui correspond à leur rôle respectif dans l’authentification par clé.
Le système affiche aussi une empreinte et un randomart, cette petite empreinte visuelle dérivée du hash de la clé publique. Ce n’est pas décoratif : cela aide à repérer une substitution de clé, surtout quand une machine change ou qu’un fichier a été transféré plusieurs fois.
- Clé privée : conserve l’identité, ne se partage jamais
- Clé publique : se copie sur le serveur Linux distant
- Passphrase : protège le fichier si le poste est compromis
- Fingerprint : permet de valider l’intégrité de la clé
Dans une logique de maintenance, le vrai confort arrive quand le nom du fichier reste explicite. Un poste, une clé, un commentaire clair : cette discipline évite de se tromper au moment de révoquer un accès ou de migrer vers une nouvelle machine.
Vérifier l’empreinte avant d’aller plus loin
La commande ssh-keygen -lvf sur la clé publique affiche l’empreinte et le randomart, ce qui permet de comparer facilement les éléments attendus. Cette étape prend quelques secondes et peut éviter une confusion pénible entre plusieurs clés générées au fil du temps.
À l’échelle d’une équipe, ce réflexe devient vite indispensable. Quand plusieurs administrateurs travaillent sur le même serveur Linux, un identifiant mal étiqueté peut suffire à rallonger un dépannage simple.
Copier la clé publique sur le serveur Linux avec authorized_keys
Le cœur de la configuration SSH se joue ici : la clé publique doit être ajoutée dans ~/.ssh/authorized_keys sur le compte distant. Une fois ce fichier en place, le serveur sait quelle identité peut se connecter sans mot de passe, à condition que les permissions soient correctes.
Deux méthodes pratiques ressortent souvent. ssh-copy-id automatise une grande partie du travail, tandis qu’un envoi via cat et ssh reste très utile lorsque l’on préfère garder le contrôle sur chaque étape.
La méthode la plus simple avec ssh-copy-id
La commande ssh-copy-id -i ~/.ssh/votre_cle.pub utilisateur@serveur commence par vérifier l’authenticité du serveur, puis demande le mot de passe du compte distant. Elle crée ensuite le dossier .ssh si besoin, ajoute la clé publique et prépare le terrain pour les connexions suivantes.
Cette méthode convient bien à un premier déploiement, surtout quand on veut réduire les risques d’erreur manuelle. En pratique, elle ressemble à un gabarit de découpe : peu spectaculaire, mais très fiable quand on suit le tracé.
La méthode manuelle avec un tube SSH
La variante suivante reste très efficace : cat ~/.ssh/id_ed25519.pub | ssh utilisateur@serveur « mkdir -p -m 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys ». Elle ajoute la clé publique à la fin du fichier distant, sans écraser les clés déjà présentes.
Le point clé réside dans les permissions. 700 pour le dossier .ssh, 600 pour authorized_keys : sans cela, OpenSSH peut refuser la connexion, même si la clé est correcte. Ce détail fait souvent la différence entre un accès sécurisé et une configuration qui semble bonne mais ne fonctionne pas.
| Élément distant | Permission attendue | Pourquoi c’est important |
|---|---|---|
| ~/.ssh | 700 | Empêche les autres utilisateurs d’y accéder |
| authorized_keys | 600 | Protège les clés autorisées à la connexion |
| known_hosts | Géré côté client | Enregistre l’empreinte du serveur connu |
Au moment de la première connexion, le client peut demander de valider l’empreinte du serveur. Cette étape n’est pas une formalité : elle évite de se connecter à la mauvaise machine sans s’en rendre compte, surtout dans un réseau local où plusieurs hôtes peuvent se ressembler.
Tester l’accès sécurisé SSH avant de couper le mot de passe
Avant toute suppression du mot de passe, il faut vérifier que la clé privée fonctionne réellement. La commande ssh -i ~/.ssh/clé_privée utilisateur@serveur force l’utilisation d’une clé précise et permet de confirmer que la configuration SSH est prête, passphrase comprise si elle existe.
Cette vérification mérite d’être faite depuis le poste client sans garder une session administrateur ouverte en parallèle sur le même canal. Ce n’est pas un luxe : c’est la différence entre une transition calme et un verrouillage involontaire.
Ce que montre la connexion réussie
Une fois la clé acceptée, la session s’ouvre sans réclamer de mot de passe du compte distant. Si une passphrase protège la clé privée, elle peut être demandée au premier usage, ou bien gérée par ssh-agent pour éviter de la ressaisir à chaque fois.
Le journal détaillé avec ssh -v montre très bien l’enchaînement : négociation SSH, proposition de la clé, acceptation par le serveur, puis ouverture de session. C’est précieux pour diagnostiquer un refus de clé, un mauvais chemin ou un fichier de permissions trop permissif.
Passer à une configuration SSH sans mot de passe
Quand la clé SSH fonctionne, seulement alors, il devient raisonnable de désactiver l’authentification par mot de passe dans /etc/ssh/sshd_config. La modification la plus courante consiste à mettre PasswordAuthentication no et à laisser PubkeyAuthentication yes, puis à recharger le service SSH pour appliquer les changements.
Sur Debian et AlmaLinux, un simple systemctl reload sshd suffit souvent à prendre en compte la nouvelle configuration sans interrompre brutalement les sessions déjà ouvertes. Ce point reste pratique en production, surtout lorsqu’un serveur Linux sert encore à plusieurs personnes.
Une mise à jour prudente du démon SSH
La logique est simple : vérifier, modifier, relire la configuration effective avec sshd -T, puis recharger. Cette séquence évite les surprises liées aux fichiers de configuration commentés ou aux distributions qui n’exposent pas exactement les mêmes chemins de service.
Un détail utile à garder en tête : l’authentification par clé protège l’accès, mais elle n’empêche pas de conserver d’autres bonnes habitudes, comme un pare-feu propre et des comptes bien nommés. La sécurité se construit rarement sur un seul verrou.
Quand ssh-agent apporte du confort sans sacrifier la sécurité
Si la clé privée est protégée par une phrase secrète, ssh-agent permet de la saisir une fois puis de la garder disponible pendant la durée voulue. Les commandes eval $(ssh-agent) et ssh-add mettent en place ce petit relais local très pratique pour les connexions répétées.
Le nettoyage est tout aussi simple avec ssh-add -D pour retirer les identités, puis ssh-agent -k pour arrêter l’agent. C’est une bonne habitude sur une machine partagée ou dans un atelier où plusieurs profils utilisent le même poste Linux.
Dans un coin d’atelier, cette logique évoque la vitrine bricolée avec un ruban LED : la mise en valeur est discrète, mais elle change tout à l’usage. SSH fait un peu la même chose quand il est bien réglé : il rend l’accès plus fluide sans exposer ce qui doit rester caché.
Quelle clé choisir pour SSH sur Linux en 2026 ?
Ed25519 reste un choix très pertinent pour la plupart des usages, avec une génération simple et une bonne sécurité. RSA peut encore convenir dans certains environnements, mais la clé Ed25519 est souvent plus directe à gérer.
Pourquoi SSH refuse parfois une clé pourtant bien copiée ?
Le problème vient souvent des permissions du dossier .ssh ou du fichier authorized_keys. Vérifiez aussi le bon utilisateur distant, le chemin de la clé et l’état réel de la configuration SSH avec sshd -T.
Faut-il protéger la clé privée avec une phrase secrète ?
Oui, c’est vivement recommandé si la machine client peut être volée ou partagée. La passphrase ajoute une couche de sécurité utile, sans empêcher l’usage quotidien avec ssh-agent si besoin.
Comment vérifier que la connexion passe bien par la clé SSH ?
La commande ssh -i ~/.ssh/clé_privée utilisateur@serveur force la clé voulue. En mode verbeux avec -v, il devient aussi possible de voir si le serveur accepte réellement la clé publique.
