Comment faire pour supprimer une clé ssh?

J'ai actuellement une vieille clé SSH téléchargé sur le serveur. Le problème est que j'ai perdu mon ~/.ssh répertoire (avec l'original du id_rsa et id_rsa.pub fichiers).

Par conséquent, je veux enlever l'ancienne clé SSH directement sur le serveur et télécharger un nouveau.

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

$> ssh-add -D

Comment faire pour supprimer une clé ssh?

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

  • Qu'est-ce avec ssh-add -d ?
  • merde, il est ssh-add-D, en majuscules
  • Vérifiez vos prises de courant qui sont utilisés par votre ssh-agent(1).
InformationsquelleAutor user1364743 | 2014-08-23
  1. 95

    Remarque qu'il y a au moins deux rapport de bug pour ssh-add -d/-D pas retrait clés:

    La cause exacte est:

    ssh-add -d/-D ne supprime que ajouté manuellement touches de gnome-keyring.

    Il n'y a pas moyen de supprimer automatiquement les touches supplémentaires.

    C'est l'origine du bug, et il est encore très présents.

    Ainsi, par exemple, si vous avez deux différents automatiquement chargé ssh identités associées à deux GitHub comptes-dire pour le travail et pour la maison, il y a aucun moyen pour basculer entre eux. GitHubtakes la première qui correspond à, de sorte que vous apparaissent toujours comme votre "home" de l'utilisateur à GitHub, avec aucun moyen de télécharger des choses à des projets de travail.

    Permettant ssh-add -d à appliquer à automatiquement chargé touches (et ssh-add -t X pour modifier la durée de vie de automatiquement-clés chargées), serait de rétablir le comportement de la plupart des utilisateurs s'attendent.

    Plus précisément, sur la question:

    Le coupable est gpg-keyring-daemon:

    • Il porte atteinte à l'exploitation normale de ssh-agent, la plupart du temps simplement de sorte qu'il peut apparaître une jolie boîte dans laquelle vous pouvez taper le mot de passe crypté de clés ssh.
    • Et pattes par le biais de votre .ssh répertoire, et ajoute automatiquement les clés qu'il trouve à votre agent.
    • Et il ne vous laisseront pas de supprimer ces clés.

    Comment cette haine? Il ne faut pas les moyens, la vie est trop courte.

    L'échec est aggravée par le fait que les plus récents des clients ssh automatiquement essayer toutes les clés dans votre ssh-agent lors de la connexion à un ordinateur hôte.

    Si ils sont trop nombreux, le serveur rejette la connexion.

    Et depuis gnome-keyring-daemon a décidé pour lui-même le nombre de touches que vous voulez que votre ssh-agent, et a chargé, ET ne VOUS laisseront PAS de les SUPPRIMER, vous êtes grillé.

    Ce bug est encore confirmé dans Ubuntu 14.04.4, aussi récemment qu'il y a deux jours (21 août 2014)

    Une solution possible:

    • Ne ssh-add -D pour supprimer tous vos manuellement touches supplémentaires. Cette verrouille également
      l'ajoutés automatiquement les clés, mais n'est pas beaucoup utilisé depuis gnome-keyring va vous demander de débloquer de toute façon lorsque vous essayez de faire une git push.
    • Accédez à votre ~/.ssh dossier et déplacer tous les fichiers de la clé à l'exception de celui que vous voulez identifier avec dans un dossier distinct appelé sauvegarde. Si nécessaire, vous pouvez également ouvrir des hippocampes et supprimer les clés à partir de là.
    • Maintenant, vous devriez être en mesure de faire git push sans problème.

    Une autre solution de contournement:

    Ce que vous voulez vraiment faire est de désactiver gpg-keyring-daemon tout à fait.

    Aller à System --> Preferences --> Startup Applications, et décocher "SSH Key Agent (Gnome Keyring SSH Agent) box " - vous aurez besoin de faire défiler vers le bas pour le trouver.

    Vous aurez toujours obtenir une ssh-agent, que maintenant il va se comporter sainement: pas de touches chargées automatiquement, vous exécutez la commande ssh-add pour l'ajouter, et si vous voulez supprimer les clés, vous pouvez. Imaginez que.

    Cette commentaires fait suggère:

    La solution est de garder gnome-keyring-manager de départ, qui était étrangement difficile, enfin, atteint en supprimant le fichier de programme de l'autorisation d'exécution.

    • Une autre option dans Ubuntu 14-16 est à utiliser l'interface utilisateur mots de passe et des clés " (vous pouvez recherche pour ssh pour le trouver) . Choisir par exemple OpenSS clés, puis cliquez droit sur la clé et choisissez supprimer. Vous devrez peut-être redémarrer votre système pour voir ce que c'est supprimée.
    • Pourquoi cette info sur le ssh-agent et ssh-add la réponse choisie? L'affiche originale a dit qu'il veut remove the old SSH key directly on the server and upload a new one. Qui sonne comme il veut modifier ~/.ssh/authorized_keys sur l'hôte distant.
    • Je suis d'accord ssh-add -D et authorized_keys sont deux opérations différentes, éléments, comme illustré dans la askubuntu.com/a/490107/5470. Mais la question était centrée autour de l'incapacité de l'enlever (phrase de passe-protégés) clé à partir de l'agent ssh. Je suppose que le authorized_keys partie de mise à jour a été effectuée de manière indépendante.
    • par ailleurs, pour supprimer les clés sur le client de l'hôte, vous pouvez également effectuer cette: ssh-add -l et de compter le nombre de touches il y a peut-être par la tuyauterie pour wc. Puis rm ~/.ssh/id_rsa ~/.ssh/id_rsa.pub Puis éventuellement le faire:ssh-add -l et vous verrez qu'il ya un nombre différent. En d'autres termes, la suppression de l'agent est automatique si vous supprimez du système de fichiers.
    • qui supprime la clé à partir du disque - lorsque l'on veut supprimer une clé à partir d'un agent, on ne veut pas jeter la clé à jamais!
    • Cette réponse me conduire à résoudre un problème en montrant forwarding avec ssh est activé. Pour aller d'un Ubuntu 16.04 la machine sur un système debian où tous les ssh informations d'identification sont transmises à un git clone a l'aide de la première clé de la chaîne au lieu de la version dans le fichier de configuration sur le Ubuntu boîte. La mauvaise clé a été de se faire sucer automatiquement et transmis au système Debian.
    • Viens un peu par ce bug sur Ubuntu 18.04. Merci beaucoup pour cette réponse!
    • C'est une vraie douleur à l'arrière. Je suis en train de travailler sur les projets de l'entreprise et sous contrat de travail en vertu d'une autre société. Cela ajoute juste le temps perdu à gérer à la fois. J'espère qu'un correctif arrive bientôt!

    InformationsquelleAutor VonC
  2. 6

    Si je ne suis malentendu, vous avez perdu votre .ssh répertoire contenant votre clé privée sur votre ordinateur local et si vous souhaitez supprimer la clé publique qui a été sur un serveur et qui permet en fonction de clé de connexion. Dans ce cas, il sera stocké dans la .ssh/authorized_keys fichier dans votre répertoire personnel sur le serveur. Vous pouvez éditer ce fichier avec un éditeur de texte et de supprimer la ligne correspondante si vous pouvez l'identifier (encore plus facile si c'est la seule entrée!). J'espère que la clé n'était pas votre seule méthode d'accès au serveur et que vous avez une autre façon de se connecter et de modifier le fichier. Vous pouvez manuellement ajouter une nouvelle clé publique à authorised_keys fichier ou utiliser ssh-copy-id. De toute façon, vous aurez besoin du mot de passe d'authentification mis en place pour votre compte sur le serveur, ou une autre identité ou de la méthode d'accès pour se rendre à l' authorized_keys fichier sur le serveur.

    ssh-add ajoute identités à votre ssh agent qui s'occupe de la gestion de vos identités localement et "la connexion à l'agent est envoyé via SSH connexion à distance, et l'utilisateur peut donc utiliser les privilèges accordés par l'identité de n'importe où dans le réseau de manière sécurisée." (page de man), donc je ne pense pas que c'est ce que vous voulez dans ce cas. Il n'a aucun moyen pour obtenir votre clé publique sur un serveur sans que vous ayez accès à ce serveur via une connexion ssh pour autant que je sais.

    • J'ai supprimé ce fichier et je peux toujours vous connecter. Donc, ce n'était certainement pas contenues dans ici... Il a été automatiquement ajouté clé mais encore, n'existe pas partout.
    InformationsquelleAutor Tim
  3. 5

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

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

    Vous pouvez supprimer le manque de clés ssh 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
    InformationsquelleAutor Derek Soike
  4. 4

    J'ai ouvert "mots de passe et Clés d'application" dans mon Unité et supprimé les clés non désirées à partir de des Clés Sécurisées -> OpenSSH clés
    Et elles sont automatiquement avaient été retirés de ssh-agent -l ainsi.

    • Attention, cela supprime aussi à partir de l'annuaire ~/.ssh
    InformationsquelleAutor Anton Balashov