Une phrase secrète de clé SSH protège le fichier, pas la route

Un disque de sauvegarde d’un ancien ordinateur portable contient encore une clé privée SSH, et quelqu’un demande si le VPN la protège. Il ne la protège pas, et il ne l’a jamais fait. Le VPN protège un chemin entre deux réseaux ; la phrase secrète protège le fichier ; l’agent protège une session en cours. Trois mécanismes différents, trois modes de défaillance différents, et une copie volée ne se soucie que des deux premiers.

La phrase secrète appartient au fichier

Une phrase secrète de clé SSH chiffre le matériel de la clé privée au repos. Ce n’est pas le mot de passe du compte envoyé au serveur, et ce n’est pas l’identifiant utilisé pour rejoindre le VPN. Les confondre mène à des changements qui ne traitent pas l’exposition.

Le manuel de ssh-keygen d’OpenSSH couvre la gestion des phrases secrètes, y compris le commutateur -p qui définit une nouvelle phrase sur une clé qui existe déjà.

Pour une clé existante, la forme de la commande est simple, et elle réécrit le fichier :

ssh-keygen -p -f ~/.ssh/id_ed25519

Utilisez le processus de maintenance et de récupération approuvé par le propriétaire de la clé, car il s’agit d’une écriture, pas d’une inspection. Ne publiez pas le fichier privé et ne placez pas une vraie phrase secrète sur une ligne de commande partagée. Changer la phrase ne rechiffre pas une copie prise plus tôt. Notez l’emplacement de l’ancienne copie dans le ticket pour que le propriétaire décide de la détruire ou non.

Une copie survit à l’ordinateur portable et au tunnel

Une fois un fichier de clé copié, la connexion VPN active de l’ordinateur portable ne dit plus rien de lui. Ce qui compte, c’est à quel point le fichier lui-même est protégé, et quels serveurs font encore confiance à la clé publique correspondante.

Changer la phrase secrète du fichier actuel ne touche pas la copie et ne retire pas la même clé publique de authorized_keys sur un serveur. La révocation et le rechiffrement sont des actions distinctes.

Traitez donc une clé privée divulguée comme un événement d’identité, pas un événement réseau. Retirez ou remplacez la clé acceptée via les serveurs et le processus d’enrôlement qui la possèdent. Arrêter le VPN limite une route à un instant donné ; ce n’est pas une révocation.

Le déverrouillage déplace le secret dans un agent

Un agent conserve des identités déchiffrées pour une authentification ultérieure, afin que l’utilisateur ne retape pas la phrase secrète à chaque connexion. C’est un confort d’usage avec sa propre frontière de sécurité.

ssh-agent peut limiter la durée pendant laquelle une identité reste chargée via son option -t, et un réglage par identité peut dépasser cette limite. Choisissez la politique pour l’agent que vous exécutez réellement au lieu de supposer qu’une déconnexion VPN oublie chaque clé chargée.

Un processus compromis après le déverrouillage de la clé est un problème différent d’un fichier chiffré volé. Transférer l’agent vers un autre hôte délègue la capacité d’authentification sans copier le fichier de clé, alors ne l’activez que pour un besoin approuvé.

Listez ce que l’agent détient actuellement avant et après un changement :

ssh-add -l

Les tâches sans surveillance ont besoin de leur propre plan

Une tâche planifiée ne peut pas répondre à une invite. Elle a besoin d’un dispositif approuvé d’identifiants de machine, et garder le secret de déverrouillage dans le même répertoire que la clé, lisible par le même compte, ne crée pas une seconde frontière.

Travaillez avec le propriétaire du service sur une livraison de secrets prise en charge ou un fonctionnement matériel, et couvrez le renouvellement, la panne et la récupération. Vouloir un humain au clavier change l’aspect de la panne par rapport à un hôte qui démarre sans personne pour surveiller.

Conservez aussi la vérification d’identité de l’hôte côté serveur et ses restrictions de compte. Une route VPN vous donne un chemin privé ; elle ne prouve pas que chaque écouteur SSH que vous atteignez est l’hôte que vous visiez. Consignez l’écouteur et l’empreinte de la clé d’hôte dans le même inventaire que la clé elle-même.

Vérifiez les frontières séparément

Testez chaque frontière avec sa propre question. Le fichier s’ouvre-t-il sans la phrase secrète ? L’agent détient-il encore l’identité après une déconnexion ? Le serveur accepte-t-il encore la clé publique ?

Deux commandes répondent à la première et à la troisième :

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

Consignez la protection du fichier, l’usage autorisé de la clé et la suppression côté serveur comme trois lignes distinctes. Un tunnel, une phrase secrète et un agent gardent chacun une partie différente de la relation, et un seul d’entre eux concerne le réseau.