Comment supprimer une clé ssh?

J'ai actuellement une ancienne clé SSH téléchargée sur un serveur. Le problème est que j'ai perdu mon ~/.sshrépertoire (avec l'original id_rsaet les id_rsa.pubfichiers).

Par conséquent, je souhaite supprimer l'ancienne clé SSH directement sur le serveur et en télécharger une nouvelle.

J'ai essayé la commande suivante sans succès:

$> ssh-add -D

Existe-t-il un moyen de supprimer complètement une clé SSH?

Notez qu'il existe au moins deux rapports de bogue pour ssh-add -d/-D ne pas supprimer les clés:

• " Rapport de bogue Debian n ° 472477: ssh-add -Dne supprime pas la clé SSH de la gnome-keyring-daemonmémoire "
• " Ubuntu: la ssh-add -Dsuppression de toutes les identités ne fonctionne pas. Aussi, pourquoi toutes les identités sont-elles ajoutées automatiquement? "

Le problème exact est:

ssh-add -d/-Dsupprime uniquement les clés ajoutées manuellement du trousseau de clés gnome.
Il n'existe aucun moyen de supprimer les clés ajoutées automatiquement.
C'est le bogue original, et il est toujours définitivement présent.

Ainsi, par exemple, si vous avez deux identités ssh différentes chargées automatiquement associées à deux comptes GitHub différents - par exemple pour le travail et pour la maison - il n'y a aucun moyen de basculer entre eux. GitHub prend le premier qui correspond, de sorte que vous apparaissez toujours comme votre utilisateur `` domestique '' sur GitHub, sans aucun moyen de télécharger des éléments dans des projets de travail.

Autoriser l' ssh-add -dapplication aux clés chargées automatiquement (et ssh-add -t Xmodifier la durée de vie des clés chargées automatiquement) rétablirait le comportement attendu par la plupart des utilisateurs.

Plus précisément, à propos du problème:

Le coupable est gpg-keyring-daemon:

• Cela perturbe le fonctionnement normal de ssh-agent, principalement pour qu'il puisse faire apparaître une jolie boîte dans laquelle vous pouvez taper la phrase de passe d'une clé ssh cryptée.
• Et il parcourt votre .sshrépertoire et ajoute automatiquement toutes les clés qu'il trouve à votre agent.
• Et cela ne vous permettra pas de supprimer ces clés.

Comment détestons-nous cela? Ne comptons pas les moyens - la vie est trop courte.

L'échec est aggravé car les nouveaux clients ssh essaient automatiquement toutes les clés de votre agent ssh lors de la connexion à un hôte.
S'il y en a trop, le serveur rejettera la connexion.
Et puisque gnome-keyring-daemon a décidé lui-même du nombre de clés que vous voulez que votre agent ssh ait, et les a chargées automatiquement, ET NE VOUS LAISSERA PAS LES SUPPRIMER, vous êtes grillé.

Ce bogue est toujours confirmé dans Ubuntu 14.04.4, il y a à peine deux jours (21 août 2014)

Une solution de contournement possible:

• Faites ssh-add -Dpour supprimer toutes vos clés ajoutées manuellement . Cela verrouille également les clés automatiquement ajoutées, mais n'est pas très utile car gnome-keyringvous demandera de les déverrouiller quand même lorsque vous essayez de faire un git push.
• Accédez à votre ~/.sshdossier et déplacez tous vos fichiers clés à l'exception de celui avec lequel vous souhaitez vous identifier dans un dossier séparé appelé sauvegarde. Si nécessaire, vous pouvez également ouvrir l'hippocampe et supprimer les clés à partir de là.
• Vous devriez maintenant pouvoir vous git pushpasser de problème.

Une autre solution de contournement:

Ce que vous voulez vraiment faire, c'est de désactiver gpg-keyring-daemoncomplètement.
Accédez à System --> Preferences --> Startup Applicationset décochez la SSH Key Agent (Gnome Keyring SSH Agent)case " " - vous devrez faire défiler vers le bas pour la trouver.

Vous obtiendrez toujours un ssh-agent, mais maintenant seulement il se comportera correctement: aucune clé n'est chargée automatiquement, vous exécutez ssh-add pour les ajouter, et si vous voulez supprimer des clés, vous pouvez. Imagine ça.

Ce commentaire suggère en fait:

La solution est de ne gnome-keyring-managerjamais démarrer, ce qui était étrangement difficile en supprimant finalement l'autorisation d'exécution du fichier programme.

Ryan Lue ajoute un autre cas intéressant dans les commentaires :

Dans le cas où cela aide tout le monde: j'ai même essayé de supprimer les id_rsaet id_rsa.pubfichiers tout à fait, et la clé était toujours à l' affiche en place.

Il s'avère que les mettre en gpg-agentcache dans un ~/.gnupg/sshcontrolfichier ; J'ai dû les supprimer manuellement à partir de là.

C'est le cas lorsque lekeygrip a été ajouté comme ici .

Si vous essayez d'effectuer une opération liée à ssh et obtenez l'erreur suivante:

$ git fetch
no such identity: <ssh key path>: No such file or directory

Vous pouvez supprimer la clé ssh manquante de votre agent ssh avec les éléments suivants:

$ eval `ssh-agent -s`  # start ssh agent
$ ssh-add -D <ssh key path>  # delete ssh key

Sauf erreur de compréhension, vous avez perdu votre .sshrépertoire contenant votre clé privée sur votre machine locale et vous souhaitez donc supprimer la clé publique qui se trouvait sur un serveur et qui permettait la connexion par clé. Dans ce cas, il sera stocké dans le .ssh/authorized_keysfichier de votre répertoire personnel sur le serveur. Vous pouvez simplement éditer ce fichier avec un éditeur de texte et supprimer la ligne correspondante si vous pouvez l'identifier (encore plus facile si c'est la seule entrée!). J'espère que cette clé n'était pas votre seule méthode d'accès au serveur et que vous disposiez d'un autre moyen de vous connecter et de modifier le fichier. Vous pouvez ajouter manuellement une nouvelle clé publique au authorised_keysfichier ou l'utiliser ssh-copy-id. Dans tous les cas, vous aurez besoin de la configuration de l'authentification par mot de passe pour votre compte sur le serveur, ou d'une autre méthode d'identité ou d'accès pour accéder au authorized_keysfichier sur le serveur.

ssh-addajoute des identités à votre agent ssh qui gère la gestion de vos identités localement et "la connexion à l'agent est transmise via des connexions distantes SSH, et l'utilisateur peut ainsi utiliser les privilèges donnés par les identités n'importe où dans le réseau de manière sécurisée". (page de manuel), donc je ne pense pas que ce soit ce que vous voulez dans ce cas. Il n'a aucun moyen d'obtenir votre clé publique sur un serveur sans que vous ayez accès à ce serveur via une connexion ssh pour autant que je sache.

J'ai ouvert l'application "Mots de passe et clés" dans mon Unity et supprimé les clés indésirables de Secure Keys -> OpenSSH clés Et elles avaient été automatiquement supprimées de ssh-agent -l aussi.

Je peux confirmer que ce bogue est toujours présent dans Ubuntu 19.04. La solution de contournement suggérée par @VonC a parfaitement fonctionné, résumant pour ma version:

• Cliquez sur l'onglet Activités dans le coin supérieur gauche
• Dans le champ de recherche qui apparaît, commencez à taper «applications de démarrage»
• Cliquez sur l'icône "Applications de démarrage"
• Dans la boîte qui apparaît, sélectionnez l'application gnome key ring manager (je ne me souviens plus du nom exact sur l'interface graphique mais il est assez distinctif) et supprimez-la.

Ce que j'ai fait ensuite était de réessayer ssh-add -D, et après le redémarrage, il ssh-add -lm'a dit que l'agent n'avait pas d'identité. J'ai confirmé que le ssh-agentdémon fonctionnait toujours avec ps aux | grep agent. J'ai donc ajouté la clé que j'utilise le plus fréquemment avec GitHub ( ssh-add ~/.ssh/id_ecdsa) et tout va bien!

Maintenant, je peux faire les opérations normales avec mon référentiel le plus fréquemment utilisé, et si j'ai parfois besoin d'accéder à l'autre référentiel qui utilise la clé RSA, je lui dédie juste un terminal avec export GIT_SSH_COMMAND="ssh -i /home/me/.ssh/id_rsa.pub". Résolu! Le mérite revient à @VonC pour avoir signalé le bogue et la solution.

Vérifiez la clé .ssh ou pas dans votre système

1. Accédez au dossier -> /Users/administrator/.ssh/id_ed25519.pub

Sinon que

2. Ouvrez le terminal.

Passé dans le terminal

3. Vérifier l'utilisateur -> ssh -T git@gitlab.com

Supprimer la clé .ssh existante

4. Supprimer la clé .ssh existante -> rm ~ / .ssh / github_rsa.pub

Créer un nouveau

5. Créer une nouvelle clé .ssh -> ssh-keygen -t rsa -b 4096 -C "votre_email@exemple.com"

6. La clé publique a été enregistrée dans "/Users/administrator/.ssh/id_ed25519.pub."

7. Ouvrez le chemin enregistré de la clé publique.
8. Copiez la clé .ssh -> Compte GitLab -> Paramètres -> Clé SSH -> Ajouter une clé
9. Tester à nouveau depuis le terminal -> ssh -T git@gitlab.com

La solution pour moi (OpenSuse Leap 42.3, KDE) était de renommer le dossier ~/.gnupgqui contenait apparemment les clés et les profils mis en cache. Après la déconnexion / connexion de KDE, ssh-add / agent est à nouveau exécuté et le dossier est créé à partir de zéro, mais les anciennes clés ont toutes disparu.

Je n'ai pas eu de succès avec les autres approches.