Gestionnaire de mots de passe SSH : stocker ses mots de passe SSH en sécurité

Quand c'est possible, remplacez les mots de passe SSH par des clés, car une clé ne traverse jamais le réseau. Les mots de passe que vous devez garder vont dans le trousseau du système ou dans un coffre chiffré, jamais dans des scripts, l'historique du shell ou sshpass -p, qui montre le mot de passe à tous les processus de la machine. Si vous avez besoin de sshpass, lisez le mot de passe dans le trousseau et passez-le avec sshpass -e.

Mis à jour le . Exécuté sur macOS 27 avec OpenSSH 10.3 : ssh-keygen et ssh-add --apple-use-keychain.

Les clés d'abord, les mots de passe ensuite

Le meilleur mot de passe SSH est celui dont vous n'avez plus besoin. Avec une clé, le serveur vérifie une signature et aucun secret ne traverse le réseau : une copie de ce que vous tapez ou un faux serveur n'obtient rien d'utile. Créez une clé et installez-la sur le serveur :

ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

Testez-la, puis désactivez la connexion par mot de passe sur le serveur, comme expliqué dans comment désactiver la connexion SSH par mot de passe. La mise en place complète de la clé se trouve dans comment générer une clé SSH Ed25519.

Les mots de passe restent pour de vraies raisons : des équipements qui n'acceptent qu'eux, des comptes que vous ne gérez pas, sudo sur le serveur, et la première connexion avant l'installation d'une clé. Ce sont ceux-là qu'il faut bien ranger.

Pourquoi sshpass -p est une mauvaise idée

sshpass tape un mot de passe dans ssh à votre place. Sa forme la plus courante est aussi la plus faible :

sshpass -p 'S3cret!' ssh deploy@203.0.113.10

Le mot de passe fait partie de la ligne de commande. Pendant l'exécution, n'importe quel utilisateur de la machine peut le lire avec ps, et il reste dans l'historique du shell. Son propre manuel qualifie -p d'option la moins sûre. Les deux autres formes valent mieux :

sshpass -f ~/.ssh/web.pass ssh deploy@203.0.113.10
SSHPASS='S3cret!' sshpass -e ssh deploy@203.0.113.10

-f lit la première ligne d'un fichier, qui doit être lisible par vous seul (chmod 600). -e lit la variable SSHPASS, qui reste visible pour les processus lancés sous votre compte. Deux autres pièges : sshpass ne sait pas répondre à la question sur la clé d'hôte, donc sur un nouveau serveur il échoue avec le code de sortie 6, et beaucoup ajoutent alors StrictHostKeyChecking=no, ce qui retire la protection contre un faux serveur. Acceptez plutôt la clé d'hôte une fois à la main.

Garder les mots de passe dans le trousseau du système

Plutôt qu'un fichier, laissez le système d'exploitation garder le mot de passe. Sur Mac, enregistrez-le dans le trousseau de session. Avec -w en dernier et sans valeur, la commande demande le mot de passe, qui n'apparaît donc jamais sur la ligne de commande :

security add-generic-password -a deploy -s ssh-web -w

Relisez-le seulement pour la commande qui en a besoin :

SSHPASS="$(security find-generic-password -a deploy -s ssh-web -w)" sshpass -e ssh deploy@web

Sur les bureaux Linux, secret-tool fait de même avec le trousseau GNOME ou KWallet :

secret-tool store --label='ssh web' service ssh host web user deploy
secret-tool lookup service ssh host web user deploy

Le trousseau se déverrouille à l'ouverture de session et garde le mot de passe chiffré sur le disque. Tout programme lancé sous votre compte peut quand même le demander, c'est pourquoi la première réponse reste une clé.

Ranger de la même façon les phrases de passe des clés

Une clé devrait avoir une phrase de passe, et le trousseau peut la retenir pour que vous ne la tapiez qu'une fois. Sur Mac :

ssh-add --apple-use-keychain ~/.ssh/id_ed25519
Host *
  UseKeychain yes
  AddKeysToAgent yes

Les détails, y compris ce qui se passe après un redémarrage, sont dans comment utiliser ssh-agent avec le trousseau macOS. Sous Linux, ssh-agent ou le trousseau du bureau joue le même rôle.

Ce que doit faire un gestionnaire de mots de passe SSH

Un gestionnaire de mots de passe généraliste stocke le secret. Pour SSH, quelques points comptent en plus :

  • Un chiffrement sur votre appareil, avec un mot de passe ou le déverrouillage du système pour l'ouvrir. S'il synchronise, le serveur ne doit voir que des données chiffrées. Le guide du coffre chiffré de bout en bout liste les questions à poser.
  • Un identifiant pour plusieurs serveurs. Un utilisateur avec son mot de passe ou sa clé, enregistré une fois et relié à chaque serveur, pour qu'un changement se fasse à un seul endroit.
  • Clés et mots de passe ensemble, pour qu'un serveur qui passe à une clé garde la même entrée.
  • Une saisie seulement à la demande. Le mot de passe va à l'invite qui le demande, pas dans le presse-papiers, pas dans un fichier.

Un gestionnaire de clés SSH avec coffre chiffré réunit ces points en un seul endroit, à côté des serveurs eux-mêmes.

Erreurs à éviter

  • Des mots de passe dans des scripts ou dans un dépôt. Ils finissent dans les sauvegardes, les journaux et les copies des autres.
  • Des mots de passe dans l'historique du shell. Dans bash, réglez HISTCONTROL=ignorespace et commencez la commande par une espace pour l'en exclure. Dans zsh, utilisez setopt HIST_IGNORE_SPACE.
  • Un seul mot de passe root partagé dans une équipe. Donnez à chacun un compte et une clé, et utilisez sudo.
  • Le même mot de passe partout. Une seule fuite ouvre alors chaque serveur.
  • Des mots de passe dans le presse-papiers. Les gestionnaires de presse-papiers et les presse-papiers synchronisés en gardent une copie.

Questions

Est-il sûr de stocker ses mots de passe SSH dans un gestionnaire ?

Oui, si le gestionnaire chiffre ses données sur votre appareil et demande un mot de passe ou le déverrouillage du système pour s'ouvrir. C'est bien plus sûr qu'un fichier texte, un script ou une note. Une clé reste meilleure que n'importe quel mot de passe stocké.

Pourquoi sshpass -p n'est-il pas sûr ?

Le mot de passe fait partie de la ligne de commande : n'importe qui sur la machine peut le voir avec ps pendant l'exécution, et il finit dans l'historique du shell. sshpass -e ou -f évitent les deux.

Peut-on mettre un mot de passe SSH dans ~/.ssh/config ?

Non. OpenSSH n'a pas d'option de mot de passe dans son fichier de configuration, et c'est voulu. Le fichier peut désigner une clé avec IdentityFile, et la phrase de passe de la clé peut rester dans le trousseau du système.

Faut-il utiliser le même mot de passe sur plusieurs serveurs ?

Non. Un seul serveur compromis ouvre alors tous les autres. Si vous devez utiliser des mots de passe, prenez-en un différent par serveur et gardez-les dans un gestionnaire.

Sources

Autres guides : Vaults chiffrés

Tous les guides