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

Настройка новой цифровой капли океана с помощью SSH-клавиш. Когда я запускаю ssh-copy-id, это то, что я получаю:

ssh-copy-id [email protected]
/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
[email protected] password: 

Number of key(s) added: 1

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

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

ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected] password:

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

[email protected]:~# eval `ssh-agent -s`
Agent pid 5715
[email protected]:~# ssh-add -l
The agent has no identities.

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

Ответ 1

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

Подтвердите с помощью ssh-add -l (опять же на клиенте), что оно действительно добавлено.

Ответ 2

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

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

ВОПРОС:

[email protected]  ~  ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected] password:

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

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

Ответ 3

У меня была такая же проблема в 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

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

Ответ 4

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

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: Permission denied (publickey).    
fatal: Could not read from remote repository.

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

Проверьте или снова добавьте открытый ключ в учетную запись Github> профиль> 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.

Спасибо.

Ответ 5

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

Я подозреваю, что проблема была вызвана неправильным вводом пин-кода tty для 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'"

Ответ 6

Это должен быть вопрос SuperUser.

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

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

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

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

Ответ 7

Да. Запустите ssh-add на клиентском компьютере. Затем повторите команду ssh-copy-id [email protected]

Ответ 8

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

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

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

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

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

[email protected]: В доступе отказано (publickey, gssapi-keyex, gssapi-with-mic)

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

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 VERBOSE (опция -v), чтобы выяснить, что не так, могут быть разные причины, ни одна из которых не может быть найдена в этом/другом потоке.

Ответ 9

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

Ответ 10

Я получил sign_and_send_pubkey: signing failed: agent refused operation ошибку 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