Ubuntu 16.04 ssh: sign_and_send_pubkey: ошибка подписи: агент отказался от операции

173

Я только что обновил свою систему 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команды. Любая помощь будет оценена.

Gamerb
источник

Ответы:

315

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

ssh-add

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

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

ssh-add -l
Рон
источник
это не -1 (число <один>), это -l (строчная L) в вашей второй команде
Даниэль Алдер
3
@ Даниэль Олдер Это действительно строчные l.
Рон
Вы правы, извините. Проблема в нижнем регистре Lшрифта "Liberation Mono" :-(
Даниэль Алдер
1
Я не думаю, что вы должны использовать ssh-addдругое, чем использовать, ssh-add -lпотому что вы можете получить слишком много записей в ssh-agent. Нет необходимости добавлять вручную. Dash > Startup Applicationsпоказывает, что ssh-agentон уже запущен, и он автоматически обнаружит такие файлы, как ~/.ssh/id_rsaи ~/.ssh/id_rsa.pub. Чтобы доказать это, вы можете использовать ssh-add -lдо и после использования ssh-keygen. Вы увидите, что он отслеживает файлы, поэтому вам не нужно добавлять их вручную.
H2ONaCl
1
Аналогично не используйте ssh-add -dи ssh-add -Dдля удаления вручную. Просто удалите файлы ключей ~/.ssh/id_rsaи ~/.ssh/id_rsa.pubи ssh-agentзаметит. Доказать, что вы можете сделать ssh-add -lдо и после удаления файлов ключей.
H2ONaCl
58

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

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

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

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

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

chmod 600 ~/.ssh/id_rsa
Антонио Фейтоса
источник
2
Путь должен быть абсолютным, например: chmod 600 ~ / .ssh / id_rsa, чтобы он работал во всех случаях.
Омар Алахмед
54

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

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. перезагрузка

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

Сэм
источник
24
Ваше решение наполовину сработало для меня (другая проблема с похожими симптомами). Используя шаг 1, я получил сообщение об ошибке Permissions 0775 for '.ssh/id_rsa' are too open. Простое решение здесь было chmod 600 .ssh/id_rsa.
Мэтт
1
Это также помогает отлаживать не только соединение с оболочкой ssh, но и git ssh auth. Использовал эту команду SSH_AUTH_SOCK=0раньше git pullи получил предупреждение о разрешениях, как Мэтт.
Серж
У меня тоже сработало. Видимо, причина была в том, что я изменил комментарий в своем ключе, и, скорее всего, агент набора ключей gnome (он же SeaHorse) все еще сохранял старую версию в памяти
маоизм
18

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

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

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

ОБНОВИТЬ:

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

Если вы хотите сохранить gnome-keyring и у вас есть 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)

Майк
источник
2
Да, но это удаляет все функциональные возможности ssh-agent, которые очень полезны
Martin
пожалуйста, отметьте нас, на каком ПК использовать sudo apt-get, наш собственный компьютер или удаленный сервер. Благодарю.
Шичен Го
Брелок для ключей на вашем локальном ПК, поскольку брелок является частью GNOME, обычно он вообще не устанавливается на сервере.
Майк
1
@MartinKonecny ​​хорошо, он просто удаляет агент ssh, предоставленный gnome, он не удаляет простой и простой консольный ssh-агент (если он у вас установлен). Проблема в том, что разнообразие гномов мешает нормальному ssh-agent. Вы все еще можете запустить ssh-agent и ввести пароли закрытого ключа на консоли / оболочке.
blubberdiblub
Это работает, если вы настроили автоматический вход в свою DE без ввода пароля, потому что тогда фактически ваш ключ-ключ gnome не будет разблокирован.
xjcl
14

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

Матиас
источник
8

В моей системе (также 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*(они больше не нужны, это было из более раннего теста) все снова прошло нормально.

Даниэль Алдер
источник
2
А что, если они вам нужны?
Гринго Суаве
@GringoSuave Хороший вопрос. Ты пробовал? Возможно формат изменился или больше не поддерживается ssh - или это ошибка. Лично я был счастлив, что мне не нужно было это проверять ...
Даниэль Олдер
Все еще не работает для меня, у меня нет решения: Could not add identity "~/.ssh/id_ed25519": communication with agent failedагент работает и настроен, насколько я могу судить.
Gringo Suave
2
@GringoSuave здесь также решение, чтобы избавиться от агента аутентификации gnome, который прикрепляет сокет агента к вашей оболочке вместо простого ssh-agentсокета. Простой ssh-agent может обрабатывать ключи ED25519, а агент аутентификации gnome - нет (помимо других проблем, которые он вызывает). Смотрите ответ Сэма askubuntu.com/a/835114/167846 или Майка askubuntu.com/a/762968/167846
blubberdiblub
7

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

qwertzguy
источник
6

У меня свежая установка 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

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

neiltheory
источник
Это сработало для меня, это должно быть выше, проголосовало
Шешанк С.
4

После обновления 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/*
Анто
источник
2

Добавление комментария, поскольку у меня была та же проблема с ключами 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 !!
Matt
источник
2

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

Любо Дьяков
источник
1

SSH-добавить

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

SSH-агент

это работает.

KST
источник
1

В моем случае проблема была вызвана 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.

Norrius
источник
0

Я попробовал пару вещей, в том числе 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! :)
недо
источник
0

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

possumkeys
источник
0

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

Fazliddin
источник
0

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

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

Сэм Брайтман
источник