SSH Key Authentication: Why and How to Use It
Vous avez probablement déjà tapé votre mot de passe sur un serveur distant. Peut-être même l'avez-vous copié depuis un gestionnaire de mots de passe, collé, appuyé sur entrée et attendu que le serveur l'accepte. Ça marche, mais c'est lent, et ce n'est pas sécurisé. À chaque fois que vous tapez un mot de passe, vous vous appuyez sur quelque chose qui peut être deviné, volé ou intercepté. L'authentification par clé SSH résout les deux problèmes à la fois : c'est plus rapide, et c'est fondamentalement plus sécurisé.
L'authentification par clé SSH remplace la connexion par mot de passe par des clés cryptographiques. Au lieu d'un mot de passe, vous utilisez une clé privée stockée sur votre machine locale et une clé publique placée sur le serveur. La clé privée est comme une clé physique pour votre maison — vous ne la partagez jamais. La clé publique est comme une serrure sur votre porte — n'importe qui peut l'utiliser, mais seule votre clé privée peut l'ouvrir. Ce mécanisme simple élimine complètement les attaques basées sur les mots de passe.
Comment Fonctionne l'Authentification par Clé SSH
SSH utilise la cryptographie asymétrique. Votre clé privée et la clé publique du serveur forment une paire. Lorsque vous vous connectez à un serveur, SSH envoie votre clé publique au serveur. Le serveur vérifie s'il a une clé privée correspondante enregistrée. Si c'est le cas, le serveur génère un défi aléatoire, le chiffre avec votre clé publique et le renvoie. Votre clé privée déchiffre le défi, le signe avec votre clé privée et le renvoie. Le serveur vérifie la signature et accorde l'accès.
Ce processus se produit automatiquement en arrière-plan. Vous ne le voyez pas, et vous n'avez rien de spécial à faire. La seule chose dont vous avez besoin est le bon fichier de clé privée au bon endroit. Si vous avez la bonne clé, SSH se connecte instantanément. Si vous n'avez pas la bonne, cela échoue immédiatement. Aucun prompt de mot de passe, aucune attente, aucun devinette.
Pourquoi Utiliser les Clés SSH au Lieu des Mots de Passe
Les mots de passe sont fondamentalement défectueux pour l'authentification à distance. Ils sont courts, prévisibles et souvent réutilisés sur plusieurs systèmes. Si un attaquant vole votre mot de passe d'un service, il peut l'utiliser pour accéder à vos serveurs. Si vous réutilisez des mots de passe, une violation n'importe où devient une violation partout. Les clés SSH résolvent ce problème en utilisant des clés longues et générées aléatoirement qui sont mathématiquement impossibles à deviner.
Les clés SSH éliminent également la nécessité de taper des mots de passe répétitivement. Lorsque vous travaillez sur un serveur toute la journée, taper des mots de passe des dizaines de fois devient fastidieux et sujet aux erreurs. Les clés fonctionnent automatiquement, vous pouvez exécuter des commandes, modifier des fichiers et gérer des services sans interruption. Cela peut sembler une commodité mineure, mais cela s'accumule. Un développeur qui économise 30 secondes par connexion économise 15 minutes par jour, 3 heures par semaine et 150 heures par an.
Sur le plan de la sécurité, les clés sont supérieures. Un mot de passe peut être forcé avec suffisamment d'essais. Une clé ne peut pas. La mathématique derrière la cryptographie asymétrique rend impossible de dériver une clé privée à partir d'une clé publique. Même si un attaquant intercepte votre clé publique lors de la transmission, il ne peut pas l'utiliser pour s'authentifier. Il aurait besoin de votre clé privée, qui reste sur votre machine locale et ne quitte jamais celle-ci.
Génération de Clés SSH
La plupart des systèmes ont déjà SSH installé. Sur Linux et macOS, vous l'avez probablement. Sur Windows, vous devrez peut-être installer OpenSSH depuis le Microsoft Store ou utiliser WSL. Une fois que vous avez SSH, générer une paire de clés est une commande en une ligne :
L'indicateur -t ed25519 spécifie le type de clé. Ed25519 est moderne, rapide et sécurisé. Il est préféré aux algorithmes plus anciens comme RSA. L'indicateur -C ajoute un commentaire à la clé, généralement votre adresse e-mail. Cela vous aide à identifier la clé plus tard. Lorsque vous exécutez la commande, SSH demande un emplacement de fichier. Appuyez sur Entrée pour utiliser le défaut (~/.ssh/id_ed25519). Ensuite, il demande un mot de passe. C'est optionnel mais recommandé.
Le mot de passe ajoute une couche de sécurité supplémentaire. Même si quelqu'un vole votre fichier de clé privée, il ne peut pas l'utiliser sans le mot de passe. Imaginez que vous chiffrez votre clé privée avec un mot de passe. Si vous ne définissez pas de mot de passe, la clé est non chiffrée et vulnérable. Si vous définissez un mot de passe, vous devez le taper à chaque fois que vous utilisez la clé. Ce compromis dépend de votre flux de travail. Pour les machines personnelles, vous pouvez peut-être omettre le mot de passe pour la commodité. Pour les machines partagées ou les serveurs sensibles, utilisez toujours un mot de passe.
Après avoir généré la clé, SSH crée deux fichiers dans votre répertoire .ssh : id_ed25519 (la clé privée) et id_ed25519.pub (la clé publique). Ne partagez jamais la clé privée. La clé publique est sûre à partager partout. En fait, vous devez la partager avec les serveurs auxquels vous voulez accéder.
Copie de Votre Clé Publique sur un Serveur
Il existe plusieurs façons de copier votre clé publique sur un serveur. La méthode la plus simple utilise SSH lui-même :
Remplacez utilisateur par votre nom d'utilisateur et nom_hôte par l'adresse IP ou le domaine du serveur. SSH-copy-id lit votre clé publique, la chiffre avec le mot de passe du serveur et l'envoie au serveur. Il ajoute la clé au fichier ~/.ssh/authorized_keys sur le serveur. Ce fichier contient toutes les clés publiques autorisées à se connecter en tant que cet utilisateur. Après avoir exécuté la commande, vous pouvez vous connecter sans mot de passe.
Si SSH-copy-id n'est pas disponible (il ne l'est pas sur certains systèmes plus anciens), vous pouvez copier la clé manuellement. Tout d'abord, obtenez votre clé publique :
Copiez la sortie, qui ressemble à ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... votre_email@example.com. Ensuite, connectez-vous au serveur via SSH :
Sur le serveur, créez le répertoire .ssh s'il n'existe pas :
Créez ou modifiez le fichier authorized_keys :
Remplacez votre_clé_publique_ici par la clé que vous avez copiée. Les permissions sont importantes. Le répertoire .ssh doit être 700 (propriétaire lecture/écriture/exécution, autres rien). Le fichier authorized_keys doit être 600 (propriétaire lecture/écriture, autres rien). Si les permissions sont incorrectes, SSH refusera d'utiliser la clé.
Test de l'Authentification par Clé SSH
Après avoir configuré la clé, testez-la. Déconnectez-vous du serveur et essayez de vous reconnecter :
Si tout est configuré correctement, vous vous connecterez sans prompt de mot de passe. Si vous avez défini un mot de passe, SSH vous le demandera. Si vous n'avez pas défini de mot de passe, vous vous connecterez instantanément. Si vous voyez un prompt de mot de passe, quelque chose ne va pas. Vérifiez les permissions sur le répertoire .ssh et le fichier authorized_keys. Vérifiez que la clé publique est dans le bon fichier. Vérifiez que vous utilisez la bonne clé.
Vous pouvez également vérifier la clé manuellement. SSH conserve une empreinte des hôtes connus. La première fois que vous vous connectez à un serveur, SSH vous demande si vous voulez faire confiance à la clé d'hôte. Il affiche une empreinte comme SHA256:9.... La prochaine fois que vous vous connectez, SSH compare l'empreinte. Si elle correspond, vous vous connectez au même serveur. Si elle ne correspond pas, quelqu'un pourrait intercepter votre connexion. Cela empêche les attaques de l'homme du milieu.
Gestion de Plusieurs Clés SSH
Vous pourriez avoir besoin de plusieurs clés pour différents usages. Une clé personnelle pour vos serveurs à la maison, une clé professionnelle pour l'infrastructure de votre entreprise, et une clé pour un projet spécifique. SSH gère cela élégamment. Vous pouvez générer plusieurs paires de clés :
L'indicateur -f spécifie le fichier de sortie. Cela crée clé_travail et clé_personnel au lieu du défaut id_ed25519. Pour utiliser une clé spécifique, SSH les vérifie dans l'ordre. Par défaut, il vérifie ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_ed25519, et ainsi de suite. Vous pouvez remplacer cela avec l'indicateur -i :
Ou vous pouvez utiliser l'indicateur -i avec SSH-copy-id :
Pour la commodité, vous pouvez configurer SSH pour utiliser une clé spécifique par défaut. Créez ou modifiez ~/.ssh/config :
Maintenant, vous pouvez vous connecter avec une simple commande :
SSH lit le fichier de configuration et utilise la bonne clé automatiquement. Cela rend la gestion de plusieurs clés sans douleur.
Résolution de Problèmes avec les Clés SSH
L'authentification par clé SSH peut échouer pour plusieurs raisons. Le problème le plus courant sont les permissions incorrectes. Si le répertoire .ssh ou le fichier authorized_keys a des permissions incorrectes, SSH rejettera la clé. Exécutez ces commandes pour corriger les permissions :
Un autre problème courant est l'utilisation de la mauvaise clé. Si vous avez plusieurs clés, assurez-vous d'utiliser celle qui est sur le serveur. Vérifiez le fichier authorized_keys du serveur :
Si votre clé n'y est pas, copiez-la à nouveau. Si elle y est, vérifiez que le format de la clé est correct. La clé doit commencer par ssh-ed25519, ssh-rsa ou un autre algorithme pris en charge. Si la clé est corrompue ou tronquée, SSH ne la reconnaîtra pas.
Parfois, le problème est la configuration du serveur SSH. Par défaut, SSH nécessite l'authentification par clé pour la connexion sans mot de passe. Si vous voulez autoriser à la fois les mots de passe et les clés, modifiez le fichier sshd_config du serveur :
Redémarrez le serveur SSH après avoir apporté des modifications :
Si vous utilisez un service SSH différent (comme OpenSSH sur macOS), utilisez la commande appropriée :
Bonnes Pratiques de Sécurité pour les Clés SSH
Les clés SSH sont sécurisées, mais seulement si vous les gérez correctement. Ne partagez jamais votre clé privée. Si vous avez besoin de partager l'accès à un serveur, copiez votre clé publique sur le serveur. La clé privée reste sur votre machine locale. Si vous perdez votre clé privée, révoquez-la immédiatement. Générez une nouvelle paire de clés et mettez à jour le fichier authorized_keys du serveur.
Utilisez des mots de passe pour les clés sensibles. Si votre clé privée est volée, le mot de passe empêche son utilisation non autorisée. Le compromis est la commodité. Vous devez taper le mot de passe à chaque fois que vous utilisez la clé. Pour les machines personnelles, cela peut être acceptable. Pour les machines partagées ou les serveurs hautement sensibles, utilisez toujours un mot de passe.
Faites tourner les clés périodiquement. Les clés n'expirent pas, mais elles devraient. Faites-les tourner tous les 6-12 mois. Cela limite les dégâts si une clé est compromise. Lorsque vous faites tourner une clé, générez une nouvelle paire, copiez la clé publique sur le serveur et supprimez l'ancienne clé de authorized_keys. C'est un processus manuel, mais c'est important.
Conclusion
L'authentification par clé SSH est plus rapide, plus sécurisée et plus pratique que la connexion par mot de passe. Elle élimine les risques de vol de mots de passe et les attaques par force brute. Elle supprime la nécessité de taper des mots de passe répétitivement. Elle s'étend facilement à plusieurs clés et plusieurs serveurs. Une fois configurée, vous vous demanderez comment vous avez géré sans elle.
Le processus de configuration est simple. Générez une paire de clés avec ssh-keygen, copiez la clé publique sur le serveur avec ssh-copy-id, et testez la connexion. Si vous rencontrez des problèmes, vérifiez les permissions sur le répertoire .ssh et le fichier authorized_keys. Utilisez la configuration SSH pour gérer plusieurs clés. Utilisez des mots de passe pour les clés sensibles. Faites tourner les clés périodiquement.
Les plateformes comme ServerlessBase simplifient la gestion des clés SSH en gérant automatiquement la configuration du proxy inverse et la fourniture des certificats SSL, vous permettant de vous concentrer sur l'utilisation des clés au lieu de les configurer. Une fois que vous avez configuré l'authentification par clé, vous vous demanderez comment vous avez géré avec des mots de passe.