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 команда. Любая помощь будет оценена.

17 ответов

Решение

Выглядит как ssh-agent уже запущен, но он не может найти ключи в приложении. Чтобы решить эту проблему, добавьте идентификаторы закрытого ключа в агент аутентификации следующим образом:

ssh-add

Тогда ты можешь ssh на ваш сервер.

Кроме того, вы можете увидеть список отпечатков пальцев всех идентификаторов, добавленных:

ssh-add -l

Простое решение

У меня была такая же проблема в Ubuntu 18.04. Это все о клиентских разрешениях закрытых ключей.

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

Права доступа к файлу были слишком открыты (0644).

Следующая команда решила это:

chmod 600 ~/.ssh/id_rsa

У меня была такая же проблема (те же симптомы)

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. Пост, касающийся решения, можно прочитать здесь.

Короче:

  1. Чтобы определить проблему, добавьте SSH_AUTH_SOCK=0 перед командой ssh. sam@xxxxx:~/.ssh$ SSH_AUTH_SOCK=0 ssh centos@123.123.123.123
  2. В случае, если это удается подключиться. Откройте приложение StartUp Application (например, с помощью функции поиска на рабочем столе) и отключите использование gnome-keyring.
  3. перезагружать

На странице представлены другие подробности в случае аналогичной проблемы с другим решением.

Я получал sign_and_send_pubkey: signing failed: agent refused operation при входе в систему на нескольких серверах читайте ответ VonC о переполнении стека для получения дополнительной информации о связанных ошибках, решение для меня заключалось в удалении gnome-keyring, удалении идентификаторов из ssh-agent и перезагрузке.

sudo apt-get autoremove gnome-keyring
ssh-add -D

Тогда все мои ключи начали работать отлично.

ОБНОВИТЬ:

Временное решение без удаления ключей

Если вы хотите сохранить гном-брелок и у вас есть agent refused operation ошибка, используйте:

eval `ssh-agent -s`
ssh-add

или использовать SSH_AUTH_SOCK=0 ssh your-server

Постоянное решение без удаления ключей

Если вы можете, gnome-keyring совместим с 4096-битным ключом RSA, так что просто сгенерируйте новый ключ с помощью:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

Загрузить открытый ключ на сервер

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

Добавить ключ ssh к агенту

ssh-add ~/.ssh/your-key-name

Это должно работать без каких-либо дополнительных хаков, и gnome-keyring может оставаться установленным.

(-C [имя пользователя] является необязательным, но требуется провайдерами, такими как Google Cloud)

После обновления до Ubuntu 18.04 я получил ту же ошибку sign_and_send_pubkey: signing failed: agent refused operation, Оказывается, это было вызвано тем, что права доступа к ключу ssh слишком открыты. Следующая команда исправила проблему для меняchmod 600 .ssh/id_rsa

В моей системе (также 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

После удаления файлов ~/.ssh/id_ed25519* (они больше не нужны, это было из более раннего теста) все снова прошло хорошо.

У меня свежая установка Ubuntu16.04, и у меня возникли аналогичные проблемы. Когда я пытался клонировать свой репозиторий из Github после того, как я скопировал свой открытый ключ в github (согласно инструкциям на github.com) и после выполнения следующей проверки ( рекомендуется на github.com):

ssh -T git@github.com

Меня приветствовали следующие:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

Чтобы исправить это быстро, не удаляя ничего и не меняя конфигурацию запуска, я просто набрал в терминале следующее:

killall gnome-keyring-daemon

Тогда клон сработал. Затем я снова запустил остановленный демон, набрав:

gnome-keyring-daemon

Позже, чтобы изменить положение вещей более постоянным образом, я последовал совету здесь

Произошло со мной, потому что мой закрытый ключ имел парольную фразу. Пришлось бежать ssh-add а затем он попросил пароль и добавил правильно. Однако теперь он не запрашивает мою фразу-пароль при подключении к машине.

gpg-connect-agent updatestartuptty /bye, затем попробуйте еще раз.

После обновления Fedora 26 до 28 я столкнулся с той же проблемой. И нет журналов

no /var/log/secure
no /var/log/messages

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

сообщение об ошибке не указывает на актуальную проблему. Проблема решена

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

Добавление комментария, поскольку у меня была та же проблема с ключами ed25519. Проблема действительно гном-брелок. Чтобы это исправить, я сделал следующее:

  • Не проверено ssh-key-agent (gnome-keyring) в "автозагрузке приложений"
  • Убил ssh-agent и gnome agent: (killall ssh-agent; killall gnome-keyring-daemon)
  • Перезапустил демон: (eval ssh-agent -s)
  • Добавьте ваш ключ: $ ssh-add id_ed25519 Введите ключевую фразу для id_ed25519: Идентификационная информация добавлена: id_ed25519
  • Profit!!

Это конец 2018 года, и эта ошибка, или ее разновидности, все еще изводят Xubuntu 16.04 и, скорее всего, другие версии Xenial. Я бы не удивился, если бы он существовал и в 18.04! Это было в некоторой форме с 2009 года, и Кармическая Коала. Повлияло на Redhat, Debian и Ubuntu. Не верьте мне на слово, посмотрите публичные сообщения об ошибках:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

И в этой ошибке, вы также найдете списки для других 3:

Рекомендации:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

В моем случае наиболее очевидным симптомом была неспособность использовать ssh-ключи с парольными фразами. Это может повлиять и на них без, так как неисправность вообще не позволяет загружать ssh-ключи! И у меня не было проблем с разрешениями, это было все gnome-keyring. Мои ключи (да, он отказался несколько, для разных SSH-серверов!) Были все 600 (rw для владельца, ничего для группы или другого), как указано во многих ответах об этом. Так что я ничего не мог изменить там.

В Xubuntu есть способ отключить элементы автозагрузки. Обычно это также возможно в Unity/Gnome/KDE, но у меня их нет, поэтому я не могу дать конкретные шаги. Не уверен в других рабочих столах. Вместо того чтобы отключать агент SSH, агент GPG и другие элементы из Gnome, которые вызывают это, и другие связанные с этим ошибки, я отключил все элементы запуска Gnome. Может быть, излишним или не вариант для некоторых, но SSH вернулся к безупречной работе при следующей перезагрузке!

  1. Откройте главное меню Whisker -> Настройки -> Сеанс и запуск.
  2. Перейдите на вкладку "Дополнительно", последняя справа.
  3. Снимите флажок (выключите) Запустите Gnome Services при запуске.
  4. Закройте и перезагрузите. Выход из системы может сделать это тоже, но перезагрузка должна точно.

Скриншот графического интерфейса, описанного выше:

Итак, поскольку я дал свое исправление выше, я надеюсь, что кто-то исправит это.

Ubuntu наверняка не удалось раздавить его навсегда, так как есть несколько билетов на несколько выпусков, которые утверждают, что это исправлено, и больше, которые говорят "регрессия", он вернулся.

Вероятно, Debian хочет надуть (помыть руки), потому что это не они, а верхний поток - это Gnome.

Redhat, вероятно, имеет исправление, доступное только для платящих клиентов. Потому что исторически Redhat является единственным крупнейшим работодателем платных разработчиков Gnome, что является щедрым на первый взгляд. Пока вы не поймете, что это означает, что у них есть финансовый стимул никогда не вносить подобные исправления в бесплатные версии, чтобы продолжать продавать подписки Redhat.

Gnome, вероятно, те, кто может легко исправить это в апстриме, а затем остальные могут протестировать и упаковать, не написав ни одной строки кода. Но билеты, которые я прочитал, говорят, что пакет томился годами без официального сопровождающего! И два человека, которые добровольно делают это сейчас (спасибо), почти так же заняты разработкой замены. Почему бы не починить спущенную шину, даже если на это потребуется год (это было десятилетие!), А не изобретать колесо первым?!

SSH-добавить

работает для меня. Но будь уверен

SSH-агент

бежит.

В моем случае проблема была вызвана GNOME Keyring. Чтобы отключить возможности SSH для gnome-keyring, не удаляя его напрямую (что часто ломается), следуйте этим инструкциям:

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

и перезапустите сеанс. Теперь вы можете запустить ssh-agent без вмешательства gnome-keyring.

Моя проблема заключалась в том, что во время обновления с Debian Stretch до Debian Buster я был вынужден перейти на systemd (из-за потери доступа к кнопкам выключения / перезагрузки в XFCE), и он перестал работать с той же ошибкой.

Наконец обнаружил ошибку Debian #851440 с решением: apt-get install dbus-user-session. Видимо это нужно, если вы хотите использовать gpg-agent (используется, например, для смарт-карт OpenPGP) и pinentry-gnome3 под systemd (под sysvinit, а обновление системы не установило его)

В итоге я сбросил свой известный файл hosts, и он сработал. Пришлось снова ввести пароль, но он, наконец, принял правильный пароль. Это было после новой установки.

Если добавление SSH_AUTH_SOCK=0 до того, как поможет команда ssh, то это ошибка набора ключей gnome. За исключением предоставленных решений и проблем, проблема может быть связана с парольной фразой. Если у вас есть ключевая фраза для ключа, то gnome keyring запрашивает ее при первом входе в систему и если вы вводите пустое по ошибке или неожиданно закрываете окно, gnome принимает его как пустую ключевую фразу и запоминает его навсегда. Ничто не помогает снова ввести пароль. Чтобы решить проблему, откройте приложение ssh keyring и перейдите в раздел "Вход" в категории "Пароли". Найдите запись, соответствующую проблемному ключу, войдите в Свойства и введите правильную фразу-пароль.

Есть еще одна причина этого, которой пока нет в любом ответе: формат PEM для файла ключей перестал быть по умолчанию для ssh-keygen до того, как Ubuntu переехала в gnome-keyring-daemon который поддерживает новый формат RFC4716.

Если вы сгенерируете новый ключ или добавите / удалите ключевую фразу из своего ключа, он может сломаться. Ключ использует ssh-keygen -m PEM перед любой другой операцией вам нужно запустить. Например, вы можете конвертировать обратно в старый формат, используя ssh-keygen -m PEM -p и ввод старой парольной фразы в качестве новой парольной фразы (которая будет пустой без парольной фразы).

Я попробовал пару вещей, в том числе ssh-add, сброс SSH (удаление.ssh/ на сервере и т. Д., Но не повезло. Так вышло, что мне просто пришлось переспать на одну ночь. Это помогло! Почему? "Я предполагаю, что ssh-agent, работающий на сервере, имел что-то в своем кэше, который был обновлен позже той ночью с теперь правильными значениями. Во всяком случае, теперь он работает как чудо. В заключение он сделал это (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! :)

Если вы являетесь пользователем KeepassXC, вам может быть интересен этот пост на GitHub

Там Lgmrszd ответил:

Могу подтвердить эту ошибку. Это происходит, если установлен флажок "Требовать подтверждения от пользователя...", после его отключения и перезапуска keepassxc он работает нормально.

Я надеюсь, что это поможет некоторым из вас решить этот особый случай.

Другие вопросы по тегам