Comprendre l'authentification par clé SSH : explication des clés publiques et privées

L'authentification par clé SSH est la méthode standard utilisée par de nombreux administrateurs, développeurs, systèmes d'intégration continue et outils de déploiement pour se connecter aux serveurs. Votre ordinateur portable conserve une clé privée, le serveur stocke la clé publique correspondante, et SSH prouve que vous possédez la clé privée sans l'envoyer sur le réseau.

Cette dernière partie est l'essentiel. Un mot de passe est un secret que vous tapez à plusieurs endroits. Une clé privée est un secret qui doit rester sur votre machine. Si vous la protégez par une phrase de passe et ne stockez que la clé publique sur les serveurs, vous obtenez une méthode de connexion à la fois plus sûre et plus facile à automatiser que les mots de passe partagés.

Le problème des mots de passe

L'authentification traditionnelle par mot de passe repose sur un secret partagé : le mot de passe. Bien que des mots de passe forts puissent offrir un niveau de sécurité décent, ils sont vulnérables à plusieurs faiblesses :

Attaques par force brute : Les attaquants peuvent essayer d'innombrables combinaisons de mots de passe jusqu'à trouver la bonne.
Attaques par dictionnaire : En utilisant des mots ou des phrases courants, les attaquants peuvent rapidement compromettre des comptes.
Keyloggers : Des logiciels malveillants peuvent capturer les frappes au clavier, révélant ainsi les mots de passe.
Hameçonnage : Des techniques d'ingénierie sociale peuvent inciter les utilisateurs à divulguer leurs identifiants.
Erreur humaine : Les utilisateurs choisissent souvent des mots de passe faibles, faciles à deviner ou réutilisés, et peuvent accidentellement les exposer.

L'authentification par clé SSH réduit ces risques car le secret privé n'est pas tapé sur le serveur distant. Cela ne rend pas les clés magiques. Une clé privée non chiffrée volée peut toujours être utilisée à mauvais escient, et un fichier authorized_keys mal géré peut devenir une porte dérobée silencieuse.

Authentification par clé SSH : un aperçu

L'authentification par clé SSH exploite la cryptographie asymétrique, un système qui utilise une paire de clés mathématiquement liées : une clé publique et une clé privée. Contrairement à la cryptographie symétrique, où la même clé est utilisée pour le chiffrement et le déchiffrement, la cryptographie asymétrique utilise une clé pour le chiffrement et une autre, différente mais liée, pour le déchiffrement.

Lorsque vous vous connectez avec des clés, le serveur vérifie si votre compte fait confiance à la clé publique proposée. Votre client signe ensuite les données d'authentification avec la clé privée correspondante. Le serveur vérifie cette signature avec la clé publique. La clé privée n'est pas téléchargée sur le serveur.

Le duo cryptographique : clés publiques et privées

Au cœur de l'authentification par clé SSH se trouvent ces deux composants distincts mais interconnectés.

La clé privée

La clé privée est votre identité secrète. C'est une longue chaîne de caractères complexe qui doit rester absolument confidentielle et ne jamais être partagée avec quiconque. Considérez-la comme la clé unique de votre coffre-fort numérique.

Critique pour la sécurité : Si votre clé privée est compromise, un attaquant pourrait usurper votre identité et obtenir un accès non autorisé à tout serveur où la clé publique correspondante a été déployée.
Emplacement : Généralement stockée sur votre machine locale (par exemple, ~/.ssh/id_rsa, ~/.ssh/id_ed25519).
Protection : Elle peut être protégée par une phrase de passe. Si quelqu'un copie le fichier de clé, la phrase de passe constitue la barrière supplémentaire entre "fichier volé" et "accès au serveur volé".

La clé publique

La clé publique est la contrepartie de votre clé privée. Elle est dérivée de votre clé privée mais ne peut pas être utilisée pour recréer la clé privée. Comme son nom l'indique, la clé publique est destinée à être partagée et placée sur tout serveur auquel vous souhaitez accéder.

Partageable : Vous pouvez distribuer votre clé publique en toute sécurité à n'importe qui ou à n'importe quel serveur sans compromettre votre sécurité.
Emplacement : Sur le serveur, les clés publiques sont généralement stockées dans le fichier ~/.ssh/authorized_keys pour chaque compte utilisateur. Chaque ligne de ce fichier représente une clé publique de confiance.
Rôle : La clé publique permet au serveur de vérifier une signature effectuée par la clé privée correspondante.

Comment fonctionne l'authentification par clé SSH : la poignée de main

Décomposons le processus étape par étape de la façon dont l'authentification par clé SSH établit une connexion sécurisée :

Génération de la paire de clés : Tout d'abord, vous générez une paire de clés publique et privée sur votre machine locale. La clé privée reste secrète et la clé publique est celle que vous distribuerez.
Déploiement de la clé publique : Vous copiez votre clé publique sur le serveur distant auquel vous souhaitez accéder. Cette clé est généralement ajoutée au fichier ~/.ssh/authorized_keys dans votre répertoire personnel sur le serveur.
Tentative de connexion : Lorsque vous initiez une connexion SSH de votre machine locale au serveur distant, votre client SSH indique qu'il souhaite s'authentifier à l'aide d'une clé.
Vérification par le serveur : Le serveur vérifie si la clé publique proposée est autorisée pour cet utilisateur.
Preuve du client : Votre client signe les données d'authentification avec la clé privée. Si la clé privée a une phrase de passe, il peut vous être demandé de la déverrouiller localement.
Vérification : Le serveur vérifie la signature à l'aide de la clé publique provenant de authorized_keys. Si la signature est valide et que le compte est autorisé à se connecter, l'authentification réussit.
Authentification accordée : Si la vérification réussit, le serveur vous accorde l'accès et une session SSH sécurisée est établie.

Crucialement, votre clé privée ne quitte jamais votre machine locale pendant tout ce processus. Seules les preuves cryptographiques qui en sont dérivées sont échangées.

Génération d'une paire de clés SSH

La génération d'une paire de clés SSH est un processus simple utilisant la commande ssh-keygen sur votre machine locale (Linux, macOS ou WSL/Git Bash sur Windows).

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

-t ed25519 : Spécifie le type de clé à créer. Ed25519 est une valeur par défaut moderne pour la plupart des nouvelles clés OpenSSH. RSA est encore courant, en particulier sur les systèmes plus anciens.
-C "[email protected]" : Ajoute un commentaire à la clé publique, ce qui vous aide à identifier son objectif ou son propriétaire.

Il vous sera demandé un fichier pour enregistrer la clé (par défaut ~/.ssh/id_ed25519) et une phrase de passe. Utilisez toujours une phrase de passe forte pour protéger votre clé privée.

Génération de la paire de clés ed25519 publique/privée.
Entrez le fichier dans lequel enregistrer la clé (~/.ssh/id_ed25519) :
Répertoire '/home/votreutilisateur/.ssh' créé.
Entrez la phrase de passe (laissez vide pour aucune phrase de passe) :
Entrez à nouveau la même phrase de passe :
Votre identification a été enregistrée dans /home/votreutilisateur/.ssh/id_ed25519.
Votre clé publique a été enregistrée dans /home/votreutilisateur/.ssh/id_ed25519.pub.
L'empreinte de la clé est : SHA256:...
L'image aléatoire de la clé est :
+--[ED25519 256]----+
|      .=+          |
|     . o. .        |
|    . + o.         |
|   o = B o.        |
|  . S @ + +        |
|   = + B .         |
|  o * * E          |
| . o o             |
|  . .              |
+----[SHA256]-------+

Après la génération, vous aurez deux fichiers dans votre répertoire ~/.ssh :

id_ed25519 (votre clé privée)
id_ed25519.pub (votre clé publique)

Assurez-vous que votre fichier de clé privée a des permissions strictes :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

Déploiement de votre clé publique

Pour utiliser l'authentification par clé, votre clé publique doit être placée sur le serveur distant auquel vous souhaitez accéder.

Utilisation de `ssh-copy-id` (recommandé)

L'utilitaire ssh-copy-id est le moyen le plus simple et le plus sûr de déployer votre clé publique. Il gère la création du répertoire ~/.ssh et du fichier authorized_keys avec les permissions correctes s'ils n'existent pas.

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@hôte_distant

Remplacez utilisateur par votre nom d'utilisateur sur le serveur distant et hôte_distant par l'adresse IP ou le nom d'hôte du serveur. Il vous sera demandé votre mot de passe pour utilisateur@hôte_distant une dernière fois pour télécharger la clé.

Déploiement manuel

Si ssh-copy-id n'est pas disponible, vous pouvez copier la clé publique manuellement :

Copiez le contenu de la clé publique : Affichez votre clé publique en utilisant cat.
```
cat ~/.ssh/id_ed25519.pub
```
Copiez la sortie entière, qui commence par ssh-ed25519 ... et se termine par votre commentaire.
Connectez-vous en SSH au serveur distant en utilisant l'authentification par mot de passe :
```
ssh utilisateur@hôte_distant
```
Entrez votre mot de passe lorsque vous y êtes invité.

Créez le répertoire ~/.ssh et le fichier authorized_keys s'ils n'existent pas :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Ajoutez votre clé publique à authorized_keys : Collez le contenu de la clé publique que vous avez copié précédemment dans le fichier authorized_keys.
```
echo "ssh-ed25519 AAAA..." >> ~/.ssh/authorized_keys
```
(Remplacez ssh-ed25519 AAAA... par le contenu réel de votre clé publique)

Connexion avec les clés SSH

Une fois votre clé publique sur le serveur, vous pouvez vous connecter simplement en spécifiant l'utilisateur et l'hôte :

ssh utilisateur@hôte_distant

Si vous avez plusieurs paires de clés ou si votre clé privée n'est pas à l'emplacement par défaut (~/.ssh/id_rsa ou ~/.ssh/id_ed25519), vous devrez peut-être la spécifier à l'aide de l'option -i :

ssh -i ~/.ssh/ma_clé_personnalisée utilisateur@hôte_distant

Si votre clé privée est protégée par une phrase de passe, il vous sera demandé de la saisir. Pour éviter de saisir la phrase de passe à plusieurs reprises au cours d'une session, vous pouvez utiliser ssh-agent.

Avantages de sécurité de l'authentification par clé SSH

Réduit le risque de devinette de mot de passe : Si la connexion par mot de passe est désactivée, les attaquants ne peuvent pas forcer brutalement ce compte via les mots de passe SSH.
Identifiants plus forts : Une clé SSH correctement générée n'est pas quelque chose qu'un humain peut deviner.
Aucun téléchargement de clé privée : Votre clé privée reste locale pendant l'authentification.
Adapté à l'automatisation : Les clés permettent des connexions scriptables sans mot de passe, ce qui est essentiel pour les outils d'automatisation et les pipelines CI/CD.
Protection par phrase de passe : L'ajout d'une phrase de passe à votre clé privée offre une couche de sécurité supplémentaire. Même si votre fichier de clé privée est volé, il reste inutilisable sans la phrase de passe.

Gestion de vos clés SSH

`ssh-agent`

ssh-agent est un programme qui s'exécute en arrière-plan et conserve vos clés privées déchiffrées en mémoire. Lorsque vous tentez de vous connecter à un serveur SSH, votre client SSH peut interroger ssh-agent pour obtenir la clé privée nécessaire, éliminant ainsi le besoin de taper votre phrase de passe à plusieurs reprises.

Pour démarrer ssh-agent et ajouter votre clé :

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

Vous entrerez votre phrase de passe une fois lors de l'ajout de la clé à l'agent.

Nommage et organisation des clés

Pour gérer plusieurs clés (par exemple, pour différentes organisations, projets ou usage personnel), envisagez d'utiliser des noms significatifs :

ssh-keygen -t ed25519 -f ~/.ssh/id_travail_projet -C "clé_projet_travail"
ssh-keygen -t ed25519 -f ~/.ssh/id_personnel_github -C "clé_github_personnelle"

Vous pouvez ensuite spécifier quelle clé utiliser avec l'option -i, ou configurer votre fichier ~/.ssh/config pour sélectionner automatiquement la clé correcte en fonction de l'hôte.

Exemple de ~/.ssh/config :

Hôte github.com
    IdentityFile ~/.ssh/id_personnel_github
    Utilisateur git

Hôte serveur-travail
    Hostname 192.168.1.100
    IdentityFile ~/.ssh/id_travail_projet
    Utilisateur devuser

Meilleures pratiques et conseils

Ne partagez jamais votre clé privée : C'est la règle d'or. Votre clé privée est votre identité numérique.
Utilisez une phrase de passe forte : Protégez votre clé privée avec une phrase de passe robuste, similaire à un mot de passe fort. Cela rend votre clé inutile même si elle tombe entre de mauvaises mains.
Faites une rotation lorsqu'il y a une raison : Générez une nouvelle clé lorsqu'un appareil est perdu, qu'un contractant quitte, qu'une clé a été partagée par erreur ou qu'un ancien algorithme ne correspond plus à votre politique.
Restreignez les permissions des fichiers : Assurez-vous que votre fichier de clé privée a les permissions 600 (rw-------) et que votre répertoire ~/.ssh a les permissions 700 (rwx------).
Désactivez l'authentification par mot de passe avec précaution : Une fois que la connexion par clé fonctionne à partir d'un deuxième terminal, de nombreux serveurs doivent définir PasswordAuthentication no dans /etc/ssh/sshd_config. Gardez l'accès à la console disponible avant de modifier cela sur les systèmes distants.
Utilisez ssh-agent : Pour plus de commodité et de sécurité, utilisez ssh-agent pour gérer vos clés, en particulier celles avec des phrases de passe.

Un modèle mental simple

La clé publique est le verrou que vous installez sur le compte du serveur. La clé privée est l'identifiant que vous conservez sur votre propre machine. La phrase de passe protège cet identifiant si le fichier est copié. Le fichier authorized_keys est la liste d'accès.

La plupart des problèmes de clé SSH proviennent de la confusion de ces éléments : copie de la clé privée sur le serveur, collage de la clé publique sous le mauvais utilisateur, utilisation du mauvais fichier d'identité, ou permissions trop ouvertes pour qu'OpenSSH leur fasse confiance. Nommez les clés par objectif, protégez les clés privées avec des phrases de passe, utilisez ssh-agent pour plus de commodité, supprimez les anciennes clés publiques lorsque l'accès doit prendre fin, et testez les modifications à partir d'un deuxième terminal avant de désactiver la connexion par mot de passe.