FlowingDev

Les clés SSH, expliquées : votre passeport numérique pour le serveur

Découvrez comment les clés SSH permettent une authentification sécurisée et sans mot de passe pour accéder aux serveurs distants, grâce à la magie de la cryptographie à clé publique.

Essayer l'outil: Générateur de clés SSH

En une phrase

Les clés SSH sont un duo de fichiers cryptographiques — un privé et secret, un public et partageable — qui vous permettent de prouver votre identité à un ordinateur distant sans taper de mot de passe.

Le problème que ça résout

Aux débuts d'Internet, si vous vouliez gérer un serveur distant, vous utilisiez un truc comme Telnet. Vous tapiez votre nom d'utilisateur et votre mot de passe, et ils traversaient le réseau en texte clair, à la vue de tous. C'était l'équivalent numérique de crier le code de votre carte bancaire au milieu d'une foule. Aïe.

Puis est arrivé SSH, le Secure Shell. Il chiffrait l'intégralité de la conversation, ce qui a représenté un pas de géant. Maintenant, vous pouviez taper votre mot de passe, et il était brouillé pendant son trajet vers le serveur. Beaucoup mieux ! Mais les mots de passe ont toujours des défauts. Ils peuvent être faibles, oubliés, devinés ou forcés par attaque brute. Gérer les mots de passe pour des dizaines de serveurs et pour toute une équipe de développeurs devient un cauchemar logistique et sécuritaire. Qui a accès à quoi ? Que se passe-t-il quand quelqu'un quitte l'entreprise ? Faut-il changer le mot de passe sur 50 serveurs et communiquer le nouveau à tout le monde ?

C'est ce problème que les clés SSH ont été conçues pour résoudre. Elles remplacent « quelque chose que vous savez » (un mot de passe) par « quelque chose que vous avez » (une clé privée). Cette méthode, appelée authentification par clé publique, est considérablement plus sûre et bien plus pratique pour les humains comme pour les systèmes automatisés. C'est la différence entre avoir un passe-partout unique et facile à voler, et une carte d'accès biométrique unique pour chaque porte que vous devez ouvrir.

Comment ça marche sous le capot

La magie derrière les clés SSH est un concept appelé cryptographie asymétrique. Contrairement à un simple mot de passe (qui est un secret symétrique — vous et le serveur connaissez la même chose), une paire de clés SSH se compose de deux clés distinctes mais liées mathématiquement.

La paire de clés publique-privée : une histoire d'amour déséquilibrée

Imaginez que vous ayez un cadenas magique et une seule clé unique. Le cadenas est votre clé publique. Vous pouvez faire un million de copies de ce cadenas et les donner à n'importe qui. Vous pouvez la publier sur votre site web, l'envoyer par e-mail à vos amis et la mettre sur chaque serveur auquel vous voulez accéder. Elle est publique ; ce n'est pas grave si elle se balade.

Votre clé privée est la seule et unique clé qui peut ouvrir ce type spécifique de cadenas. Vous gardez cette clé comme la prunelle de vos yeux. Vous la conservez sur votre ordinateur, ne la partagez jamais et, idéalement, la protégez avec une phrase de passe.

  • La clé privée peut créer une signature numérique.
  • La clé publique peut vérifier qu'une signature a bien été faite par sa clé privée correspondante.

Point crucial : la clé publique ne peut pas être utilisée pour deviner la clé privée. La relation mathématique ne fonctionne que dans un sens, d'où le terme « asymétrique ».

La poignée de main pour l'authentification

Alors, comment ça se passe quand vous essayez de vous connecter ? Disons que vous tapez ssh user@server.com.

  1. La présentation : Votre ordinateur (le client) frappe à la porte du serveur. « Salut, je voudrais me connecter en tant que user. Je crois que ma clé publique est l'une de celles que tu reconnais. Voici son ID. »
  2. Le défi : Le serveur regarde dans le fichier ~/.ssh/authorized_keys de l'utilisateur user. Ce fichier est simplement une liste des clés publiques autorisées à se connecter en tant que cet utilisateur. Le serveur trouve une clé publique correspondante. « Ah, je vois ton cadenas public ! Je te crois, mais j'ai besoin d'une preuve. Pour prouver que tu as la clé privée, s'il te plaît, signe ce message aléatoire à usage unique que je viens d'inventer : R2-D2_is_the_true_hero. »
  3. La signature : Votre client reçoit le défi. Il utilise votre clé privée pour créer une signature numérique unique pour ce message spécifique. Il renvoie ensuite cette signature au serveur. Votre clé privée elle-même ne quitte jamais, au grand jamais, votre ordinateur.
  4. La vérification : Le serveur reçoit la signature. Il prend la clé publique qu'il a dans ses dossiers et l'utilise pour vérifier la signature par rapport au message de défi original. Comme seule votre clé privée a pu produire cette signature exacte pour ce message exact, le serveur sait qu'il vous parle bien à vous.
  5. Accès autorisé : Les calculs sont bons. Le serveur dit : « La signature est valide. Bienvenue ! » et vous accorde une session shell, le tout sans qu'un mot de passe n'ait jamais traversé le réseau.

Types de clés : un portrait de famille (RSA, ECDSA, Ed25519)

Toutes les clés ne se valent pas. Elles utilisent différents algorithmes mathématiques pour générer les paires de clés et les signatures. Vous verrez couramment trois types principaux :

Algorithme En bref Taille de clé (typique) Verdict
RSA La vieille garde. Basé sur la difficulté de factoriser d'énormes nombres premiers. 2048 ou 4096 bits Toujours robuste et largement supporté, mais lent et nécessite de grandes clés selon les standards modernes.
ECDSA Le standard moderne. Utilise les maths des courbes elliptiques pour être plus petit et plus rapide. 256 ou 384 bits Excellent choix. Une clé ECDSA de 256 bits offre une sécurité similaire à une clé RSA de 3072 bits.
Ed25519 La nouvelle star. Un type spécifique de clé à courbe elliptique encore plus rapide. 256 bits Le meilleur choix si supporté. Rapide, sûr et conçu pour résister à certaines attaques.

Aujourd'hui, Ed25519 est généralement le choix recommandé pour ses performances et sa sécurité supérieures.

Qu'est-ce qu'une empreinte (fingerprint) ?

Une clé publique est une longue et moche chaîne de caractères. Ce n'est pas quelque chose que vous pouvez facilement retenir ou comparer. Une empreinte (ou fingerprint) est un résumé court et unique de la clé publique, créé en passant la clé dans une fonction de hachage (comme SHA256).

SHA256:88+EM65U024w0E7sF2w8w3n98w/L3t8d7f6e5g4h

Elle agit comme un numéro de série lisible par un humain. Lorsque vous vous connectez à un serveur pour la toute première fois, SSH vous montrera l'empreinte de la clé publique du serveur et vous demandera si vous lui faites confiance. C'est votre seule chance d'empêcher une attaque de type « homme du milieu » (man-in-the-middle) en vérifiant cette empreinte via un autre canal sécurisé (comme appeler l'admin sys et la lui lire).

Histoires vécues

Le script de déploiement automatisé

Maya, une ingénieure DevOps, gérait une flotte de 20 serveurs web. Chaque fois qu'elle déployait une nouvelle version de l'application de son entreprise, son script devait se connecter à chaque serveur pour récupérer le dernier code et redémarrer le service. Son premier script lui demandait le mot de passe du serveur 20 fois de suite, ce qui était d'une lenteur exaspérante. Sa version suivante avait le mot de passe codé en dur dans le script, ce qui a fait tiquer le RSSI (Responsable de la Sécurité des Systèmes d'Information). Finalement, elle a généré une unique paire de clés SSH dédiée aux déploiements. Elle a ajouté la clé publique à tous les 20 serveurs. Maintenant, son script s'exécute sans accroc et en toute sécurité, se connectant à chaque machine en quelques secondes sans aucune intervention manuelle.

La leçon : Les clés SSH sont la pierre angulaire de l'automatisation sécurisée et sans mot de passe.

Le départ du prestataire

Une petite startup a engagé un freelance, David, pour un projet de trois mois. Pour lui donner accès au serveur de pré-production, le tech lead, Chen, a simplement demandé la clé SSH publique de David et l'a ajoutée au fichier authorized_keys du serveur. David pouvait désormais se connecter en toute sécurité et faire son travail. À la fin du contrat, tout le processus d'« offboarding » de Chen pour l'accès au serveur a consisté en une seule commande : ouvrir le fichier authorized_keys et supprimer la ligne contenant la clé de David. L'accès a été révoqué instantanément et proprement, sans mots de passe partagés à changer ou dont il faudrait se soucier.

La leçon : Les clés SSH offrent un contrôle d'accès granulaire, auditable et facilement révocable pour chaque utilisateur.

Le premier git push sur GitHub

Sam, un nouveau développeur, vient de rejoindre une équipe et de cloner leur dépôt de code privé. Après avoir fait son premier changement, il a essayé de faire un git push. Il a été accueilli par une erreur « Permission denied ». L'entreprise, comme beaucoup d'autres, avait désactivé l'authentification par mot de passe sur GitHub pour des raisons de sécurité. Le wiki interne lui a indiqué de générer une nouvelle clé SSH, puis de naviguer dans ses paramètres GitHub et de coller le contenu de sa clé publique (id_ed25519.pub) dans la section « SSH and GPG keys ». Après cela, il a pu push son code en utilisant l'URL SSH du dépôt (git@github.com:...). GitHub utilisait exactement le même mécanisme de défi-réponse pour vérifier que c'était bien Sam qui envoyait le code.

La leçon : Les clés SSH sont la norme pour s'authentifier auprès de services allant au-delà du simple accès shell, y compris la plupart des plateformes d'hébergement de code.

Erreurs et pièges courants

  • Partager votre clé privée. N'envoyez jamais, au grand jamais, votre clé privée (id_ed25519 ou id_rsa) à qui que ce soit ou ne la téléchargez nulle part. C'est votre secret. La partager anéantit complètement l'intérêt de ce modèle de sécurité.
  • Oublier une phrase de passe. Votre clé privée n'est qu'un fichier sur votre disque. Si votre ordinateur portable est volé, un attaquant peut simplement la copier. Une phrase de passe robuste chiffre ce fichier, obligeant le voleur à craquer à la fois le mot de passe de votre ordinateur et la phrase de passe de votre clé. C'est une couche de défense essentielle.
  • Coller la clé privée dans un champ pour clé publique. C'est une erreur facile à commettre. Vous configurez un nouveau service, il vous demande votre clé publique, et vous copiez-collez accidentellement le contenu du mauvais fichier. Vérifiez toujours que la clé que vous partagez se termine par .pub.
  • Utiliser des clés faibles et anciennes. Générer une clé RSA de 1024 bits de nos jours est une mauvaise idée. Elles sont potentiellement vulnérables au déchiffrement par des attaquants bien financés. Tenez-vous-en aux standards modernes : Ed25519 ou au moins une clé RSA de 4096 bits.
  • Taper « oui » sans réfléchir. La première fois que vous vous connectez à un nouvel hôte, SSH vous avertit que l'authenticité de l'hôte ne peut être établie et vous montre son empreinte. Ne l'acceptez pas aveuglément. C'est à ce moment qu'une attaque de type « Man-in-the-Middle » peut se produire. Vérifiez l'empreinte via un autre canal si vous êtes sur un réseau non fiable.

Pourquoi c'est un sujet pour vous

Si vous êtes développeur, admin sys, ingénieur DevOps, ou toute personne ayant besoin de se connecter à un ordinateur distant, les clés SSH ne sont pas juste une fonctionnalité « sympa à avoir » — elles sont fondamentales. C'est la manière professionnelle, sécurisée et efficace de gérer l'accès aux machines.

Vous devriez penser aux clés SSH lorsque :

  • Vous configurez un nouveau serveur (dans le cloud ou sur site).
  • Vous écrivez un script qui doit se connecter à une autre machine (scp, sftp, rsync, git).
  • Vous mettez en place l'accès pour un nouveau membre de l'équipe.
  • Vous vous connectez à GitHub, GitLab ou Bitbucket.
  • Vous voulez arrêter de taper des mots de passe.

Apprendre à utiliser les clés SSH est un rite de passage qui vous fait passer du statut d'utilisateur occasionnel de machines distantes à celui d'opérateur compétent.

Pour aller plus loin

Théorie bouclée. Place à la pratique — 100 % dans ton navigateur.

Essayer l'outil: Générateur de clés SSH