Как решить «sign_and_send_pubkey: ошибка подписи: агент отказался от операции»?

Настройка новой капли Digital Ocean с ключами SSH. Когда я бегу, ssh-copy-idто получаю:

ssh-copy-id user@012.345.67.89
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@012.345.67.89'"
and check to make sure that only the key(s) you wanted were added.

Однако, когда я затем пытаюсь подключиться к ssh, происходит следующее:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

После ввода пароля я вхожу в систему нормально, но это, конечно, в первую очередь сводит на нет цель создания ключа SSH. Я решил взглянуть на серверную часть ssh-agent и вот что у меня получилось:

user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.

user / .ssh / authorized_keys также содержит запись ключа ssh-rsa, но find -name "keynamehere"ничего не возвращает.

Запустите ssh-addна клиентском компьютере, который добавит ключ SSH к агенту.

Подтвердите ssh-add -l(снова на клиенте), что он действительно был добавлен.

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

/var/log/secure
/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/*

У меня была такая же проблема в Linux Ubuntu 18 . После обновления с Ubuntu 17.10 каждая команда git будет отображать это сообщение.

Чтобы решить эту проблему, убедитесь, что у вас есть правильные разрешения для id_rsaиid_rsa.pub .

Проверьте текущий номер chmod с помощью stat --format '%a' <file>. Должно быть 600 для id_rsa и 644 для id_rsa.pub.

Чтобы изменить разрешение на файлы, используйте

chmod 600 id_rsa
chmod 644 id_rsa.pub

Это решило мою проблему с обновлением.

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

У меня это сработало.

chmod 600 ~/.ssh/id_rsa

У меня была ошибка при использовании gpg-agent в качестве моего ssh-агента и использовании подраздела gpg в качестве моего ssh-ключа https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Я подозреваю, что проблема была вызвана неправильным вводом PIN-кода для gpg, вызванным моей командой sleep + lock, используемой в моей конфигурации sway

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

или просто сон / приостановка

Сбросьте tty для ввода пин-кода, чтобы устранить проблему

gpg-connect-agent updatestartuptty /bye > /dev/null

и исправление моей команды sway sleep + lock:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"

К этой ошибке:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Проверьте или снова добавьте открытый ключ в Github account> profile> ssh.

Решил вот так:

# chmod 400 ~/.ssh/id_rsa

# ls  ~/.ssh/id_rsa -ls  
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26  2017 /home/reinaldo/.ssh/id_rsa

# git pull                                 
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.

Спасибо.

Причины появления ошибки SSH могут быть разными:

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

Некоторые из них могут быть связаны с проблемами, выделенными другими ответами (см. Ответы в этой ветке), некоторые из них могут быть скрыты и, следовательно, потребуют более тщательного исследования.

В моем случае появилось следующее сообщение об ошибке:

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

user@website.domain.com: в доступе отказано (publickey, gssapi-keyex, gssapi-with-mic)

Единственный способ найти реальную проблему - вызвать опцию -v verbose, которая привела к печати большого количества отладочной информации:

debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1

Обратите внимание, что в строке говорится key_load_public: No such file or directory относится к следующей строке, а не к предыдущей.

Итак, что на самом деле SSH говорит, так это то, что он не может найти указанный файл открытого ключа, id_rsa.website.domain.com-certи это, похоже, было проблемой в моем случае, поскольку мой файл открытого ключа не содержал -certсуффикса.

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

Суть в том, ИСПОЛЬЗУЙТЕ РЕЖИМ ГЛОБАЛЬНОЙ ЗАПИСИ SSH (опция -v), чтобы выяснить, что не так, могут быть разные причины, ни одна из которых не может быть найдена в этом / другом потоке.

Это скорее вопрос суперпользователя.

Правильно, у меня такая же ошибка внутри MacOSX SourceTree, однако внутри терминала iTerm2 все работает просто денди.

Однако проблема, похоже, заключалась в том, что у меня работает два ssh-agent ; (

Первый из них /usr/bin/ssh-agent(он же MacOSX), а затем установлен /usr/local/bin/ssh-agentзапущенный HomeBrew .

Запуск терминала из SourceTree позволил мне увидеть различия SSH_AUTH_SOCK, с помощью которых lsofя нашел два разных ssh-agents, а затем я смог загрузить ключи (используяssh-add ) в систему по умолчанию ssh-agent(т.е. /usr/bin/ssh-agent) SourceTree снова работал.

Да. Запустите ssh-add на клиентской машине. Затем повторите команду ssh-copy-id userserver@012.345.67.89

Для меня проблема заключалась в неправильном копировании / вставке открытого ключа в Gitlab. Копия принесла дополнительную прибыль. Убедитесь, что вы вставляете однострочный ключ.

У меня тоже sign_and_send_pubkey: signing failed: agent refused operationошибка. Но в моем случае проблема была не в томpinentry пути.

В моей ${HOME}/.gnupg/gpg-agent.confв pinentry-programсобственности указывал на старый путь pinentry. Исправление пути и перезапускgpg-agent исправленного для меня.

Я обнаружил это, просмотрев журналы с journalctl -f. Вот такие строки журнала, которые содержат неверный путь:

Jul 02 08:37:50 my-host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-host gpg-agent[12677]: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed

Мне нужно поделиться, так как я потратил слишком много времени на поиск решения

Вот решение: https://unix.stackexchange.com/a/351742/215375

Я использовал эту команду:

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

gnome-keyring не поддерживает сгенерированный ключ.

Удаление -oаргумента решило проблему.

В моем случае проблема заключалась в том, что связка ключей GNOME содержала недопустимую парольную фразу для использования ключа ssh. Потратив неприличное количество времени на устранение этой проблемы, я запустил seahorseи обнаружил, что запись содержит пустую строку. Я могу только догадываться, что это было вызвано ошибкой при вводе парольной фразы при первом использовании некоторое время назад, а затем, вероятно, отменой запроса или около того, чтобы вернуться к командной строке. Обновление записи с использованием правильной ключевой фразы сразу решило проблему. Удаление этой записи (из связки ключей «логин») и повторный ввод ключевой фразы в этом первом приглашении (и установка соответствующего флажка) тоже решает эту проблему. Теперь агент получает правильную парольную фразу из связки ключей разблокировки при входе с именем «логин» и больше не запрашивает парольную фразу и не отказывается от операции. Конечно YMMV.

Что тут работало: на клиенте

1) ssh-add

2) ssh-copy-id пользователь @ сервер

Ключи были созданы некоторое время назад с помощью простого "ssh-keygen -t rsa". Я отправил сообщение об ошибке, потому что я скопировал открытый ключ ssh с клиента на сервер (с ssh-id-copy) без предварительного запуска ssh-add, поскольку я ошибочно предположил, что добавил их некоторое время назад.

быстрое примечание для тех, кто недавно обновился до «современной» версии ssh [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 сентября 2019 г.] - поставляется с fedora 31, похоже, больше не принимает старые ключи SHA256 DSA (мои датированы 2006 годом!) - создал новый ключ rsa, общедоступный добавлен в авторизованный, закрытый на клиенте, и все работает отлично.

спасибо за предыдущие предложения, особенно ssh -v был очень полезен