如何删除ssh密钥?


153

我目前在服务器上上传了旧的SSH密钥。问题是我丢失了~/.ssh目录(包括原始目录id_rsaid_rsa.pub文件)。

因此,我想直接在服务器上删除旧的SSH密钥并上传新的SSH密钥。

我尝试了以下命令,但未成功:

$> ssh-add -D

在此处输入图片说明

有没有办法完全删除SSH密钥?


什么ssh-add -d呢?
user2196728 2014年

5
该死的,它是ssh-add -D,大写
Alexander Mills

检查ssh-agent(1)正在使用的套接字。
德怀特·斯潘塞

Answers:


128

请注意,至少有两个错误报告ssh-add -d/-D 删除密钥:

确切的问题是:

ssh-add -d/-D从gnome-keyring中仅删除手动添加的键。
无法删除自动添加的键。
这是原始错误,仍然肯定存在。

因此,例如,如果您有两个不同的自动加载的ssh身份与两个不同的GitHub帐户相关联-例如工作和家庭,则无法在它们之间进行切换。GitHub是第一个匹配的,因此您总是以GitHub的“家庭”用户身份出现,而无法将内容上传到工作项目中。

允许ssh-add -d应用到自动加载的密钥(并ssh-add -t X更改自动加载的密钥的生存期),将恢复大多数用户期望的行为。


更确切地说,关于这个问题:

罪魁祸首是 gpg-keyring-daemon

  • 它破坏了ssh-agent的正常运行,主要是为了使它弹出一个漂亮的框,您可以在其中输入加密的ssh密钥的密码。
  • 它通过你的爪子 .ssh目录,并自动将找到的所有密钥添加到您的代理中。
  • 而且它不会让您删除这些键。

我们怎么讨厌这个?让我们不要指望方式-生活太短了。

由于新的ssh客户端在连接到主机时会自动尝试ssh-agent中的所有密钥,因此该故障更加严重。
如果太多,服务器将拒绝连接。
而且由于gnome-keyring-daemon自行决定了您希望ssh-agent拥有多少个密钥,并且已经自动加载了它们,并且不会让您删除它们,所以您敬酒。

早在两天前(2014年8月21日),Ubuntu 14.04.4中仍确认了此错误。


可能的解决方法:

  • 不要ssh-add -D删除所有手动添加的钥匙。这也锁定了自动添加的键,但是用处不大,因为gnome-keyring尝试执行时会要求您将它们解锁git push
  • 导航到您的~/.ssh文件夹,然后将除要标识的密钥文件以外的所有关键文件移动到称为备份的单独文件夹中。如有必要,您也可以打开海马并从那里删除密钥。
  • 现在您应该可以git push毫无问题地进行操作了。

另一个解决方法:

您真正想要做的是gpg-keyring-daemon完全关闭。
转到System --> Preferences --> Startup Applications,然后取消选择“ SSH Key Agent (Gnome Keyring SSH Agent)”框-您需要向下滚动才能找到它。

您仍然会得到一个ssh-agent,直到现在它会正常运行:不会自动加载任何密钥,您可以运行ssh-add来添加它们,如果您想删除密钥,则可以。设想。

该评论实际上表明:

解决的办法是gnome-keyring-manager避免启动,这是最终要删除程序文件的执行许可才能实现的目标,这很难做到。


Ryan Lue 在评论中添加了另一个有趣的极端案例:

万一这对任何人都有帮助:我什至尝试完全删除id_rsaid_rsa.pub文件,并且密钥仍在显示。

原来gpg-agent是将它们缓存在一个~/.gnupg/sshcontrol文件中 ; 我不得不从那里手动删除它们。

这时候的情况keygrip已经被添加在这里


1
Ubuntu 14-16中的另一种选择是使用gui'Passwords and keys'(您可以通过ssh搜索找到它)。选择例如OpenSS密钥,然后右键单击该密钥并选择Delete。您可能需要重新启动系统才能看到已将其删除。
user3257693

2
为什么此信息ssh-agentssh-add所选答案有关?原始海报说他想remove the old SSH key directly on the server and upload a new one。听起来他想~/.ssh/authorized_keys在远程主机上进行编辑。
H2ONaCl

1
这个答案使我解决了启用ssh转发时出现的问题。从Ubuntu 16.04计算机转到Debian系统,在该系统中所有ssh凭证都被转发,这git clone是使用链中的第一个密钥而不是Ubuntu框上的配置文件中的版本。坏钥匙被自动吸收并转发到Debian盒子。
redfive

1
这是后部的真正痛苦。我正在从事公司项目,并签约在另一家公司工作。这只会增加管理两者的时间。我希望尽快解决!
joshlsullivan

1
万一这对任何人都有帮助:我什至尝试完全删除id_rsaid_rsa.pub文件,并且密钥仍在显示。原来gpg-agent正在将它们缓存在~/.gnupg/sshcontrol文件中;我不得不从那里手动删除它们。
瑞安·吕

10

如果您尝试执行与ssh相关的操作并收到以下错误:

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

您可以使用以下方法从ssh代理中删除丢失的ssh密钥:

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

9

除非引起我的误会,否则您会丢失.ssh包含本地密钥的目录,因此您要删除服务器上允许基于密钥的登录的公共密钥。在这种情况下,它将存储在.ssh/authorized_keys服务器主目录中的文件中。您可以仅使用文本编辑器编辑此文件,如果可以识别它,则删除相关的行(即使它是唯一的条目,也更容易!)。我希望密钥不是您访问服务器的唯一方法,并且您还有其他登录和编辑文件的方法。您可以手动将新的公钥添加到authorised_keysfile或使用ssh-copy-id。无论哪种方式,您都需要在服务器上为您的帐户设置密码验证,或者需要其他某种身份或访问方法来获取authorized_keys服务器上的文件。

ssh-add向ssh代理添加身份,该ssh代理在本地处理您的身份管理,并且“与该代理的连接通过SSH远程登录转发,因此用户可以安全地使用网络中任何位置的身份赋予的特权。” (手册页),因此在这种情况下,我认为这不是您想要的。据我所知,如果您无法通过ssh登录名访问该服务器,就无法将您的公钥放入服务器。


我删除了此文件,但仍然可以连接。因此,它绝对不包含在此处...这是一个自动添加的键,但在任何地方都不存在。
拉里


1

我可以确认此错误在Ubuntu 19.04中仍然存在。@VonC建议的解决方法非常有效,总结了我的版本:

  • 单击左上角的“活动”选项卡
  • 在出现的搜索框中,开始输入“启动应用程序”
  • 单击“启动应用程序”图标
  • 在弹出的对话框中,选择gnome钥匙圈管理器应用程序(无法记住GUI上的确切名称,但名称足够独特)并将其删除。

我接下来要做的是再试ssh-add -D一次,重新启动后ssh-add -l告诉我该代理没有身份。我确认我仍在ssh-agent运行守护程序ps aux | grep agent。因此,我添加了我最常用于GitHub的密钥(ssh-add ~/.ssh/id_ecdsa),一切都很好!

现在,我可以使用最常用的存储库进行正常操作,并且如果偶尔需要访问使用RSA密钥的其他存储库,我只需使用它专用一个终端即可 export GIT_SSH_COMMAND="ssh -i /home/me/.ssh/id_rsa.pub"。解决了!感谢@VonC指出错误和解决方案。


1

检查.ssh密钥是否在系统中

  1. 转到文件夹-> /Users/administrator/.ssh/id_ed25519.pub

如果不是

  1. 打开终端。

过去在航站楼

  1. 检查用户-> ssh -T git@gitlab.com

删除现有的.ssh密钥

  1. 删除现有的.ssh密钥-> rm〜/ .ssh / github_rsa.pub

创建新的

  1. 创建新的.ssh密钥-> ssh-keygen -t rsa -b 4096 -C“ your_email@example.com”

  2. 公钥已保存在 “ /Users/administrator/.ssh/id_ed25519.pub”中。

  3. 打开公共密钥保存的路径。
  4. 复制.ssh密钥 -> GitLab帐户->设置-> SSH密钥->添加密钥
  5. 从终端 -> ssh -T git@gitlab.com 再次测试

0

我的解决方案(OpenSuse Leap 42.3,KDE)是重命名文件夹 ~/.gnupg显然包含高速缓存的密钥和配置文件。KDE注销/登录后,ssh-add / agent再次运行,并且从头开始创建该文件夹,但是旧密钥已全部消失。

其他方法我没有成功。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.