Espace client
Linux•24 juillet 2026• 0 vues

Clés SSH : générer, installer et sécuriser l'accès à votre serveur

Clés SSH : générer, installer et sécuriser l'accès à votre serveur

Le mot de passe est le maillon faible de tout serveur exposé sur Internet. Il peut être deviné, réutilisé, intercepté ou cassé par force brute. L'authentification par clé SSH résout le problème à la racine : au lieu d'un secret que l'on tape, on utilise une paire de clés cryptographiques quasi impossible à deviner. C'est plus sûr, et au quotidien, c'est aussi plus pratique : plus de mot de passe à saisir à chaque connexion.

Ce guide couvre tout le cycle de vie d'une clé SSH sur un VPS Linux : comprendre le principe, générer une paire de clés moderne avec ssh-keygen, l'installer sur le serveur, se connecter, utiliser l'agent SSH, puis désactiver complètement l'authentification par mot de passe pour verrouiller l'accès.

Comment fonctionne une paire de clés SSH ?

L'authentification par clé repose sur deux fichiers complémentaires :

  • La clé privée reste sur votre ordinateur. Elle ne doit jamais quitter votre machine ni être partagée. C'est votre secret.
  • La clé publique se dépose sur le serveur. Elle peut circuler librement : connaître la clé publique ne permet pas de reconstituer la clé privée.

À la connexion, le serveur envoie un défi que seule la clé privée correspondante peut résoudre. Si la preuve est valide, l'accès est accordé sans qu'aucun secret ne transite sur le réseau. C'est ce qui rend la méthode à la fois plus sûre qu'un mot de passe et résistante à l'écoute.

Prérequis

  • Un accès à votre VPS sous Linux (Ubuntu, Debian…), en SSH.
  • Un terminal sur votre poste : Terminal sous macOS/Linux, ou PowerShell / Windows Terminal sous Windows (OpenSSH y est intégré depuis Windows 10).
  • Quelques minutes. C'est le tutoriel le plus simple du parcours de sécurisation, et le plus rentable.

Générer une paire de clés SSH avec ssh-keygen

La génération se fait sur votre ordinateur, pas sur le serveur. Ouvrez votre terminal et lancez :

ssh-keygen -t ed25519 -C "[email protected]"

Quelques explications :

  • -t ed25519 choisit l'algorithme. Ed25519 est aujourd'hui le standard recommandé : clés courtes, très rapides et très sûres. Si vous devez composer avec un système ancien qui ne le supporte pas, repliez-vous sur -t rsa -b 4096.
  • -C ajoute un commentaire (typiquement votre email) pour identifier la clé plus tard.

ssh-keygen pose ensuite deux questions :

  1. L'emplacement du fichier : validez le chemin par défaut (~/.ssh/id_ed25519) en appuyant sur Entrée.
  2. Une phrase secrète (passphrase) : c'est un mot de passe qui chiffre votre clé privée sur le disque. Choisissez-en une. Ainsi, même si votre ordinateur est compromis, la clé volée reste inutilisable. L'agent SSH (voir plus bas) vous évitera de la retaper à chaque connexion.

Deux fichiers sont créés dans ~/.ssh/ :

id_ed25519        → votre clé privée (à garder secrète)
id_ed25519.pub    → votre clé publique (à déposer sur le serveur)

Installer la clé publique sur le serveur

Le but est d'ajouter votre clé publique au fichier ~/.ssh/authorized_keys de votre utilisateur sur le VPS. La méthode la plus simple est ssh-copy-id :

ssh-copy-id utilisateur@IP_DU_SERVEUR

La commande vous demande une dernière fois votre mot de passe (celui du serveur), puis copie et configure tout automatiquement, avec les bonnes permissions. C'est terminé.

Si ssh-copy-id n'est pas disponible (sous Windows, par exemple), la méthode manuelle fonctionne partout :

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh utilisateur@IP_DU_SERVEUR "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Sous macOS/Linux, l'équivalent :

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

Se connecter avec sa clé

Testez immédiatement la connexion par clé, avant de toucher à quoi que ce soit d'autre :

ssh utilisateur@IP_DU_SERVEUR

Si vous avez défini une phrase secrète, elle vous est demandée (c'est celle de la clé, pas celle du serveur). Vous êtes connecté sans le mot de passe du serveur : la clé fonctionne. Ne passez à l'étape de désactivation du mot de passe qu'une fois cette connexion confirmée.

Utiliser l'agent SSH pour ne plus retaper la passphrase

Saisir la phrase secrète à chaque connexion devient vite fastidieux. L'agent SSH garde votre clé déverrouillée en mémoire pour la durée de votre session. Démarrez-le puis ajoutez votre clé :

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

Vous saisissez la passphrase une seule fois ; les connexions suivantes sont transparentes. Sous macOS, vous pouvez enregistrer la clé dans le trousseau système avec ssh-add --apple-use-keychain. Sous Windows, activez le service ssh-agent (Get-Service ssh-agent | Set-Service -StartupType Automatic) puis ssh-add.

Pour lister les clés actuellement chargées dans l'agent :

ssh-add -l

Le fichier de configuration SSH (bonus pratique)

Pour ne plus taper l'IP et l'utilisateur, créez un raccourci dans ~/.ssh/config sur votre poste :

Host monvps
    HostName 203.0.113.10
    User monutilisateur
    IdentityFile ~/.ssh/id_ed25519

Une simple commande ssh monvps suffit alors à vous connecter.

Désactiver l'authentification par mot de passe

C'est l'étape qui verrouille réellement votre serveur : une fois la connexion par clé confirmée, on interdit totalement le mot de passe. Ainsi, même la meilleure attaque par force brute ne sert plus à rien.

Avertissement : ne faites ceci qu'après avoir vérifié que la connexion par clé fonctionne. Gardez idéalement une seconde session SSH ouverte pendant la manipulation, en filet de sécurité.

Sur le serveur, éditez la configuration du démon SSH :

sudo nano /etc/ssh/sshd_config

Assurez-vous d'avoir ces directives (décommentez-les et ajustez les valeurs) :

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password

PermitRootLogin prohibit-password autorise root uniquement par clé (ou le désactive avec no si vous passez toujours par un utilisateur sudo, ce qui est préférable). Enregistrez, puis rechargez le service :

sudo systemctl restart ssh

Sur certaines distributions récentes, la configuration peut être surchargée par un fichier dans /etc/ssh/sshd_config.d/. Si PasswordAuthentication no semble ignoré, vérifiez ce dossier. Testez ensuite une nouvelle connexion : le mot de passe ne doit plus être accepté.

Bonnes pratiques

  • Une clé par appareil. Générez une paire distincte sur chaque machine d'où vous vous connectez, plutôt que de recopier la même clé privée partout. En cas de perte d'un appareil, vous retirez juste sa clé publique du serveur.
  • Protégez la clé privée par une passphrase. Une clé privée sans phrase secrète offre un accès total à quiconque met la main sur le fichier.
  • Ne partagez jamais la clé privée. Seul le fichier .pub se transmet.
  • Sauvegardez vos clés dans un endroit sûr : perdre sa clé privée, c'est perdre l'accès configuré.
  • Combinez avec un pare-feu. Restreindre le port SSH et n'ouvrir que le nécessaire renforce l'ensemble voir l'étape UFW du parcours ci-dessous.

Dépannage : « Permission denied (publickey) »

C'est l'erreur la plus fréquente, et elle vient presque toujours des permissions de fichiers. SSH refuse d'utiliser un dossier ou un fichier de clés trop permissif. Sur le serveur, corrigez :

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

Autres pistes courantes :

  • Mauvais utilisateur ou mauvaise clé : vérifiez que vous vous connectez avec le bon compte et que la clé privée correspondante est bien présente (ssh -i ~/.ssh/id_ed25519 utilisateur@IP).
  • Diagnostic détaillé : ajoutez -v (voire -vvv) à votre commande ssh pour voir précisément quelle clé est proposée et où ça bloque.
  • authorized_keys mal formé : la clé publique doit tenir sur une seule ligne.

Foire aux questions

Ed25519 ou RSA ? Ed25519 pour tout serveur moderne : plus court, plus rapide, aussi sûr. RSA 4096 reste un repli valable pour d'anciens systèmes.

Que faire si je perds ma clé privée ? Vous ne pourrez plus vous connecter avec. Reconnectez-vous par un autre moyen (autre clé, console de secours du VPS), puis retirez l'ancienne clé publique de authorized_keys et ajoutez-en une nouvelle.

Puis-je utiliser la même clé sur plusieurs serveurs ? Techniquement oui : il suffit de déposer la même clé publique sur chacun. Mais préférez une clé par poste de travail plutôt qu'une clé unique dupliquée sur toutes vos machines.

Les clés SSH fonctionnent-elles sous Windows ? Oui, OpenSSH est intégré à Windows 10 et 11. Toutes les commandes de ce guide fonctionnent dans PowerShell ou Windows Terminal.

Le parcours sécurisation de votre serveur

L'authentification par clé est la première brique d'un serveur bien défendu celle qui ferme la porte d'entrée. Pour compléter la démarche sur votre VPS Linux, enchaînez avec le reste du parcours :

  1. Clés SSH remplacer le mot de passe par une authentification par clés (vous êtes ici).
  2. UFW fermer tous les ports inutiles avec un pare-feu simple (guide à venir).
  3. Fail2ban bannir automatiquement les attaquants qui insistent (guide à venir).
  4. Certbot chiffrer vos services avec un certificat SSL Let's Encrypt (guide à venir).

Retrouvez l'ensemble de nos tutoriels dans la documentation Linux. En moins de dix minutes, vous transformez l'accès à votre serveur : de « mot de passe vulnérable » à « clé cryptographique impossible à deviner ».

Retour à la documentation