Impossible de supprimer les clés de ssh-agent. Même le redémarrage n'aide pas


18

Il y a peu de temps, j'ai remarqué qu'il y avait trois clés dans mon agent ssh que je ne pouvais pas supprimer. ssh-add -la montré trois clés; J'ai couru ssh-add -Det on m'a dit "Toutes les identités ont été supprimées."; mais un immédiat a ssh-add -lmontré les trois mêmes clés.

Si je me déconnecte puis me reconnecte, les clés sont toujours là. Si je redémarre la machine, les clés sont toujours là. Si je supprime le répertoire du trousseau de clés /tmp, je ne peux plus me connecter ssh-agent, mais lors de la déconnexion et de la reconnexion, les clés sont de retour. Ils sont invulnérables.

Les clés sont les miennes, pas celles des autres, pour autant que je sache. Je peux accéder à mes services locaux habituels avec eux. Mais lorsque j'ajoute à nouveau l'une des clés avec ssh-add, donnant le chemin d'accès à un fichier de clé privée, la nouvelle clé a une apparence différente dans la sortie de ssh-add -l:

2048 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f /home/jruser/.ssh/jruser-keyname-20110418 (RSA)

par rapport à l'original:

2048 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f jruser 04/18/2011 keyname (RSA)

Existe-t-il un moyen de rendre raisonnablement compte de ce comportement? Je suppose qu'il y a vraiment deux questions:

  1. Comment les clés ont-elles pu être conservées même lors des redémarrages? Ma connaissance de base de sshsuggère que les clés doivent toujours être ajoutées manuellement.

  2. Pourquoi ssh-agent -Dme ment-t-on à propos de la suppression des identités?


Il y a aussi un bug Fedora / Red Hat: bugzilla.redhat.com/show_bug.cgi?id=1205546
spoovy

Réponses:


11

Il semble que ce soit un bug. J'ai un comportement similaire dans Ubuntu 10.10. Une recherche Google a trouvé un rapport de bogue pour Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472477

Pour supprimer les clés supplémentaires que j'avais affichées, je les ai simplement déplacées hors du répertoire ~ / .ssh.


Oui! Cela fonctionne pour moi. Merci! J'utilise Debian Wheezy beta 4.
Tarrasch

3
Enfin bouclé et enquêté. Le coupable est gnome-keyring-daemon, qui a) charge automatiquement toutes les clés dans ~ / .ssh, et b) refuse de les abandonner. La solution est d'empêcher gnome-keyring-manager de démarrer, ce qui était étrangement difficile à réaliser en supprimant l'autorisation d'exécution du fichier programme.
Sean

Y a-t-il une solution à cela qui n'implique pas d'entraver gnome-keyring-manager? c'est-à-dire, en fixant gnome-keyring-manager pour qu'il supprime les clés qui lui sont demandées?
Phil

1
Nous sommes en 2018 et c'est toujours d'actualité. Je dois retirer les clés de ~ / .ssh
Carson Ip

1
Sensationnel. Supprimez les clés de ~ / .ssh et placez-les dans un autre répertoire comme mentionné @CarsonIp, puis utilisez une commande ssh-agent dans votre bashrc pour charger manuellement les clés ssh supplémentaires de l'autre répertoire. PIMA!
Ligemer

3

Vos clés sont stockées sous forme de fichiers dans le répertoire caché: /home/jruser/.ssh/ c'est ainsi qu'elles persistent après les redémarrages. Je suppose que ssh-add -D les supprime de la mémoire, mais lorsque vous redémarrez, ils sont lus dans le répertoire .ssh et vous les avez donc à nouveau.


4
Mais ssh-add -Dne les supprime pas de la mémoire. Cela n'a aucun effet.
Sean
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.