Il y a quelques brèves discussions sur la ssh-agent -tfonctionnalité existante à [1], et il y avait un article remontant à 2001 sur debian-devel [2] souhaitant une fonctionnalité de timeout d'inactivité. Il y a une discussion similaire ici sur SE [3] pour le concours.
Je dois me demander comment le reste de la planète protège les clés ssh - manque-t-il quelque chose d'évident pour que cela soit un point douloureux pour moi, et apparemment personne d'autre? Plus précisément, je pense aux interactions ssh scriptées, comme avec ansible. Il semble qu'aujourd'hui, vos choix soient:
- Réglez la durée de vie de votre clé dans l'agent sur une période de temps inquiétante, par exemple. 1h ou quelle que soit la durée maximale d'exécution de vos scripts (je doute que beaucoup de gens autorisent leur délai de réautorisation sudo à s'étirer aussi longtemps!) - mais
seahorse/ àgnome-keyring-daemonpeine même supporte autant [4] - Gardez vos scripts de longue durée et continuez à ressaisir votre phrase secrète toutes les 5/10/15 minutes: vous pouvez maintenant être regardé facilement saisir votre phrase secrète 20 fois par jour
- Hackez votre propre solution de brassage maison pour imiter cette fonctionnalité manquante, peut-être en conjonction avec le
TMOUTshell var de votre shell (merci les gens sur freenode #openssh IRC pour cette suggestion) - Aucune durée de vie de clé définie, c'est-à-dire que votre agent garde votre clé chargée pour toujours ou jusqu'à ce que vous tuiez / redémarriez
Si vous utilisez de brefs délais d'attente d'agent ssh, des phrases de passe fortes et différents fichiers de clés pour chaque type de rôle que vous authentifiez: cela mène à une journée très frustrante!
J'ai expérimenté avec gpgkey2ssh et les cartes à puce, mais cela ne résout pas vraiment ce problème particulier: je veux toujours la fonctionnalité ssh-agent et je ne veux pas avoir à ré-authentifier toutes les 5 minutes juste pour éviter que mes clés privées ne soient exposées en mémoire alors que mon ordinateur est inactif.
Suis-je en train de mal faire?
[1] Configuration du délai d'expiration par défaut pour l'agent SSH
[2] https://lists.debian.org/debian-devel/2001/09/msg00851.html
[3] /server/518312/putty-pageant-forget-keys-after-period-of-inactivity
[4] https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/129231
la source
ssh-agentest indépendante du type de session dont elle fait partie (par exemple, session tty, session X11 ou autre). La seule chose que je voudrais dire si vos scripts automatisés ne devraient probablement pas dépendre de la clé chargée dans votre agent. Ils devraient probablement avoir chacun leur propre clé privée, qui est autorisée via des commandes forcées sur les serveurs appropriés à exécuter uniquement les commandes à distance spécifiques que chaque script doit exécuter. Cela vous permettrait bien sûr d'exécuter ceux de cron etc ...ssh-agentà savoir quand une session est inactive, mais au moins démarrer le délai d'expiration à partir du moment où la dernière opération de signature s'est produite, pas seulement à chaque fois qu'elle assh-agentété lancée. De plus, j'utilise déjà des comptes utilisateur et des fichiers clés distincts pour chaque rôle de script, sudoers permet de ne créer que 1 ou 2 commandes si nécessaire, et j'ai regardélshellpour verrouiller les choses plus loin. Mais tout cela ne me dispense toujours pas de devoir protéger mes fichiers de clés: simplement parce quesudo zfs sendc'est la seule commande autorisée pour une clé donnée, c'est une commande assez puissante pour quiconque possède cette clé!ControlMaster/ControlPath/ControlPersist(voirman ssh_config) pour votre script. Au moins si sa seule connexion à un hôte.ssh-agentgarder mes clés chargées jusqu'à ce que je redémarre (ce qui pourrait prendre des semaines).Réponses:
Si cela vous concerne, vous pouvez facilement utiliser l'
xscreensaver-command -watchinterface pour exécuterssh-add -Dlorsque l'écran est verrouillé. Consultez la page de manuel pour un exemple très simple.la source