Gestion des clés SSH et accès sécurisé

SSH chiffre un shell distant ou une copie de fichier. Les clés remplacent les mots de passe répétés : une clé privée reste sur votre machine ; le serveur stocke la moitié publique. Cette leçon couvre la génération de clés, les « clés_autorisées », les agents et les pièges comme le transfert.

Widgets : tableau de comparaison compare le mot de passe et l'authentification par clé pour les problèmes opérationnels. Le graphique montre où la confiance est stockée (clé privée du client par rapport aux clés_autorisées du serveur). L'explorateur de code parcourt keygen → installation → autorisations → agent. Le code à onglets couvre la configuration multi-hôtes et la confiance par clé d'hôte.

Mot de passe vs clé publique
Les lignes correspondent aux menaces et aux opérations : automatisation de l'échelle des clés ; les mots de passe ne dépendent que de la mémorisation humaine.
Mot de passePaire de clés SSH
Force brute / pulvérisationVulnérable aux devinettes et à la réutilisation sur plusieurs sitesEspace clé Ed25519/RSA ; combiner avec le numéro d'authentification par mot de passe sur les serveurs
Automatisation / CITentations intégrant des secrets ; MFA interrompt les flux non interactifsCI utilise des clés de déploiement ou des certificats de courte durée ; Ansible utilise ssh-agent ou sshpass (à éviter)
Rotation / révocationChanger le mot de passe partout où il a été réutiliséRotation de la paire de clés : ajoutez une nouvelle clé publique, vérifiez la connexion, supprimez l'ancienne ligne des clés_autorisées
AuditDifficile de prouver quel humain a utilisé le compte partagéCommentaires par clé dans authorized_keys ; clés par hôte dans la configuration
Modèle de confiance

Graphique : le centre est sshd. Votre clé privée ne quitte jamais l'ordinateur portable : elle signe simplement un défi. Le serveur n'a jamais vu que la ligne public copiée dans authorised_keys. La compromission du serveur ne fait pas fuir votre fichier de clé privée du disque (sauf si vous transférez l'agent de manière imprudente).

Nœuds de clic : l'ordinateur portable contient du matériel de clé privée ; Le fichier serveur authorised_keys répertorie les clés publiques autorisées : une ligne par clé, peut inclure les préfixes from="10.0.0.*" ou command="…" pour force-command.
sshd sur le serveur
💻Votre ordinateur portable
🔐~/.ssh/id_ed25519
📋~/.ssh/authorized_keys
▶
Commandes quotidiennes
L'ordre compte : générer → installer la clé publique → corriger les autorisations → charger dans l'agent. Un mauvais chmod sur ~/.ssh est la raison n°1 pour laquelle l'authentification pubkey « échoue silencieusement ».
bash
1
ssh-keygen -t ed25519 -C "you@example.com"
▼
2
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
▼
3
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
▼
4
eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519
▼
Fichier de configuration pour de nombreux hôtes
Alias et clés
sshconfig
Host prod
  HostName 10.0.1.50
  User deploy
  IdentityFile ~/.ssh/prod_ed25519
  ServerAliveInterval 60

Redirection d'agent : à utiliser avec parcimonie

ssh -A saute à travers les bastions mais expose votre agent à la racine distante : une racine malveillante sur un saut pourrait utiliser vos clés. Préférez plutôt ProxyJump dans ~/.ssh/config.
ProxyJump : ssh -J bastion app.internal
Protégez les clés privées avec des jetons matériels (FIDO2) pour un accès à grande valeur.
Ne confiez jamais de clés privées à Git : utilisez des gestionnaires de secrets ou des informations d'identification de courte durée dans CI.