Ubuntu 16.04 ssh: sign_and_send_pubkey: сбой подписи: агент отказался от операции
Я только что обновил свою систему Ubuntu с 15.10 по 16.04, полностью уничтожив раздел Ubuntu 15 из моей системы.
После установки Ubuntu 16.04 я воссоздал свои ssh-ключи, поскольку я забыл их резервное копирование, но всякий раз Я пытаюсь использовать ssh, я получаю sign_and_send_pubkey: signing failed: agent refused operation, это немного раздражает, поскольку он позволяет мне перейти на мой ssh-сервер, но git отказывается выталкивать код с помощью ssh.
Я уже нажал клавиши на сервер используя ssh-copy-id.
Сервер, с которым я подключаюсь, является сервером Ubuntu 16.04, обновленным с помощью команды do-release-upgrade. Любая помощь будет принята с благодарностью.
8 ответов
У меня была та же проблема (такие же симптомы)
sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
... но решение было другим.
Проблема исходила от использования GNOME-KEYRING. Сообщение, ссылающееся на решение, можно прочитать здесь.
Короче:
Определите проблему, добавив SSH_AUTH_SOCK = 0 перед командой ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123 В случае успешного подключения. Откройте приложение StartUp Application (например, используя функцию поиска на рабочем столе) и отключите использование gnome-keyring. ПерезагрузкаНа другой странице представлены другие сведения в случае аналогичной проблемы с другим решением.
-
1Ваше решение наполовину сработало для меня (другая проблема с подобными симптомами). Используя шаг 1, я получил сообщение об ошибке Permissions 0775 for '.ssh/id_rsa' are too open. Простым решением здесь было chmod 600 .ssh/id_rsa. – Matt 26 March 2018 в 19:25
Я получал sign_and_send_pubkey: signing failed: agent refused operation при входе на несколько серверов, читал ответ VonC на Stack Overflow для получения дополнительной информации о связанных ошибках, решение для меня заключалось в удалении gnome-keyring, удалении идентификаторов из ssh-agent и перезагрузке.
sudo apt-get autoremove gnome-keyring
ssh-add -D
Затем все мои клавиши начали работать отлично.
-
1Да, но это удаляет все функциональные возможности ssh-agent, которые являются супер полезными – Martin Konecny 17 January 2017 в 19:42
-
2обратите внимание на то, на каком ПК можно использовать sudo apt-get, собственный компьютер или удаленный сервер. Благодарю. – Shicheng Guo 15 June 2017 в 06:52
-
3Брелок на вашем собственном локальном ПК, потому что Keyring является частью GNOME, он обычно не устанавливается на сервере вообще. – Mike 15 June 2017 в 09:20
-
4@MartinKonecny хорошо, он просто удаляет агент ssh, предоставляемый gnome, он не удаляет простой и простой консольный ssh-agent (если у вас есть установленный). Проблема в том, что разнообразие гномов мешает нормальному ssh-agent. Вы все еще можете запустить ssh-agent и ввести секретные ключи на консоли / оболочке. – blubberdiblub 18 March 2018 в 07:15
В моей системе (также Ubuntu 16.04, пытаясь подключиться к github) у меня был файл id_ed25519 в моей .ssh-папке, из-за чего ssh-add не удалось:
$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed
После удаления файлов [ f3] (они больше не нужны, это было из предыдущего теста), все прошло отлично.
-
1
-
2@GringoSuave Хороший вопрос. Ты пробовал? Возможно, формат изменился или больше не поддерживается ssh - или это ошибка. Лично я был счастлив, что мне не пришлось проверять это ... – Daniel Alder 21 October 2016 в 12:39
-
3Все еще не работаю для меня, у меня нет решения: Could not add identity "~/.ssh/id_ed25519": communication with agent failed, агент работает и настроен, насколько я могу судить. – Gringo Suave 21 October 2016 в 22:09
-
4@GringoSuave решение здесь также должно избавиться от агента аутентификации гнома, который наклеивает сокет агента на вашу оболочку вместо обычного ssh-agent сокета. Простой ssh-агент способен обрабатывать ключи ED25519, тогда как агент аутентификации гномов не является (помимо других проблем, которые он вызывает). См. Ответ sam askubuntu.com/a/835114/167846 или Mike askubuntu.com/a/762968/167846 – blubberdiblub 18 March 2018 в 07:20
Случилось со мной, потому что у моего личного ключа была фраза. Пришлось запустить ssh-add, а затем запросить кодовую фразу и добавить правильно. Однако теперь он не запрашивает мою кодовую фразу, когда ssh'ing на машине.
Добавление комментария, поскольку у меня была такая же проблема с ключами ed25519. Проблема в том, что это гном-ключ. Чтобы исправить это, я сделал следующее:
Unchecked ssh-key-agent (gnome-keyring) в «приложениях запуска» Убит агент ssh-агента и gnome: (killall ssh-agent; killall gnome- keyring-daemon) Повторно запустил демон: (eval ssh-agent -s) Добавьте свой ключ: $ ssh-add id_ed25519 Введите кодовую фразу для id_ed25519: Добавлен идентификатор: id_ed25519 Прибыль!После обновления до Ubuntu 18.04 я получил ту же ошибку sign_and_send_pubkey: signing failed: agent refused operation. Оказывается, это было вызвано тем, что права на ключ ssh слишком открыты. Следующая команда исправила проблему для меня chmod 600 .ssh/id_rsa
Я попробовал пару вещей, среди прочего, ssh-add, сброс SSH (удаление .ssh / на сервере и т. д., но не повезло. Так получилось, что мне просто пришлось спать над ним на одну ночь. помогло! Почему? Я предполагаю, что у ssh-агента, работающего на сервере, было что-то в его кеше, которое было обновлено позже той ночью с теперь правильными значениями. Во всяком случае, теперь это работает как шарм. Для этого он сделал это (Ubuntu 16.04 на localhost, 14.04 на сервере).
# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug. 11 09:55 authorized_keys
# no other magic going on! :)
Я закончил тем, что сбросил мой файл известных хостов, и он сработал. Если бы снова ввести пароль, но он, наконец, принял правильный пароль. Это было после новой установки.