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

Похоже, что он 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

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

ОБНОВИТЬ:

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

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

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

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

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

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

После обновления 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.

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

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

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

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

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