Как удалить ключ ssh?


154

В настоящее время у меня есть старый ключ SSH, загруженный на сервер. Проблема в том, что я потерял свой ~/.sshкаталог (с оригиналом id_rsaи id_rsa.pubфайлами).

Следовательно, я хочу удалить старый ключ SSH прямо на сервере и загрузить новый.

Я попробовал следующую команду без успеха:

$> ssh-add -D

введите описание изображения здесь

Есть ли способ полностью удалить ключ SSH?


Что с ssh-add -d?
user2196728

5
черт возьми, это ssh-add -D, прописные буквы
Александр Миллс,

Проверьте ваши сокеты, которые использует ваш ssh-agent (1).
Дуайт Спенсер

Ответы:


129

Обратите внимание, что существует по крайней мере два сообщения об ошибках для 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-агента, и автоматически их загрузил, И НЕ ПОЛУЧИТ УДАЛИТЬ ИХ, вы тост.

Эта ошибка все еще подтверждается в Ubuntu 14.04.4, всего два дня назад (21 августа 2014 г.)


Возможный обходной путь:

  • Делать, ssh-add -Dчтобы удалить все ваши добавленные вручную ключи. Это также блокирует автоматически добавленные ключи, но не очень полезно, так gnome-keyringкак попросит вас разблокировать их в любом случае, когда вы попытаетесь сделать a 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не запускаться никогда, что было странным образом затруднено, в конечном итоге, путем удаления разрешения на выполнение программного файла.


Райан Лю добавляет еще один интересный случай в комментариях :

На случай, если это кому-нибудь поможет: я даже попытался удалить id_rsaиid_rsa.pub файлы вообще, а ключ был все еще показывает вверх.

Оказывается, gpg-agentкэшировал их в ~/.gnupg/sshcontrolфайле ; Я должен был вручную удалить их оттуда.

Это тот случай , когда был добавлен , как здесь .keygrip


1
Другой вариант в Ubuntu 14-16 - использовать графический интерфейс «Пароли и ключи» (вы можете найти ssh, чтобы найти его). Выберите, например, ключи OpenSS, затем щелкните правой кнопкой мыши ключ и выберите «Удалить». Вам может потребоваться перезагрузить систему, чтобы увидеть, что она удалена.
user3257693

2
Почему эта информация о ssh-agentи ssh-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_rsaи id_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_keysфайл или использовать ssh-copy-id. В любом случае вам потребуется пароль, установленный для вашей учетной записи на сервере, или другой способ идентификации или доступа, чтобы получить доступ к authorized_keysфайлу на сервере.

ssh-addдобавляет идентификационные данные к вашему ssh-агенту, который локально управляет вашими идентификационными данными, и «соединение с агентом перенаправляется через удаленные входы SSH, и пользователь может таким образом безопасно использовать привилегии, предоставляемые идентификационными данными в любом месте сети». (man page), так что я не думаю, что это то, что вы хотите в этом случае. Насколько я знаю, он не может получить ваш открытый ключ на сервер, если у вас нет доступа к нему через логин ssh.


Я удалил этот файл, и я все еще могу подключиться. Так что это определенно не было здесь ... Это был автоматически добавленный ключ, но до сих пор нигде не существует.
Ларри

5

Я открыл приложение «Пароли и ключи» в своем Unity и удалил ненужные ключи из ключей Secure Keys -> OpenSSH. И они также автоматически были удалены из ssh-agent -l .


2
Остерегайтесь, что это также удаляет их из каталога~/.ssh
Питер В. Мёрк

1

Я могу подтвердить, что эта ошибка все еще присутствует в Ubuntu 19.04. Обходной путь, предложенный @VonC, работал отлично, суммируя для моей версии:

  • Нажмите на вкладку Действия в верхнем левом углу.
  • В появившемся окне поиска начните вводить «запуск приложений»
  • Нажмите на значок «Запуск приложений»
  • В появившемся окне выберите приложение менеджера ключей gnome (не могу вспомнить точное имя в графическом интерфейсе, но оно достаточно различимо) и удалите его.

Затем я попытался 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 снова запускается, и папка создается с нуля, но старые ключи исчезли.

У меня не было успеха с другими подходами.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.