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


114

Настройка новой капли 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"ничего не возвращает.

Ответы:


201

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

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


7
Боже, потратил два часа, пытаясь исправить это, и это все, что было! Исправлены соединения bitbucket и acquia ssh
Ронни

19
Здесь это не полностью исправлено, поскольку я использую gpg-agentдля работы SSH. У меня уже есть enable-ssh-supportв , gpg-agent.confно все же сообщение об ошибке. Я нашел в списке рассылки, чтобы запустить это gpg-connect-agent updatestartuptty /bye: bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394
Роланд

1
Мне просто нужно было убить gpg-agent, а затем запустить его снова.
Шубин

3
Когда вы генерируете новый SSH-ключ, он ssh-addдолжен быть вызван, ssh-agentчтобы узнать о новом закрытом ключе (согласно linux.die.net/man/1/ssh-agent ).
Alex

Отлично! Я воссоздал свой SSH-ключ, и это начало происходить. После ssh-addсработало! Спасибо.
hbobenicio

66

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

У меня .ssh/не было необходимых разрешений, потому что я создал его сам вручную.
Brent Bradburn

1
Похоже, что некоторые версии не позволяют видеть ваши ключи другим пользователям. Спасибо!
alan ocallaghan

если файлы .ssh / * создаются одним и тем же пользователем (не root), нам не о чем беспокоиться, поскольку он будет иметь необходимые разрешения.
Anto

1
Я должен тебя ценить. Я столкнулся с этой проблемой только сейчас. Используя ваш метод, решил это.
Земля

56

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

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


3
Я столкнулся с этой проблемой после миграции Ubuntu с 16.04 LTS на 18.04 LTS, это решение сработало для меня.
Munish Chandel

То же самое и здесь, после обновления Ubuntu до 18.04 я столкнулся с этой проблемой. Это решение исправит это.
Cartucho

Когда id_rsa.pubиспользуется в процессе аутентификации клиента?
Dimitri Kopriwa

Если у вас много ключей, вы должны использовать что-то вроде этого внутри ~/.ssh:chmod 600 id_*
lifeisfoo

11

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

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

chmod 600 ~/.ssh/id_rsa

8

У меня была ошибка при использовании 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'"


1
Спасибо. У меня была эта проблема несколько дней назад, я использую gpg, как и вы, и прокомментировал gpg-connect-agent updaterstartuptty /bye > /dev/nullмой ~ / .zshrc, раскомментировав эту строку, я решил мою проблему.
J.Adler

4

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

# 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.

Спасибо.


2

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


0

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

Правильно, у меня такая же ошибка внутри 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 снова работал.



0

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


0

У меня тоже 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

0

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

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

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

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

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

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


0

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


0

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

1) ssh-add

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

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


0

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

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


Вы обязательно должны избавиться от ключей DSA или ключей RSA <2048 бит. Есть способы разрешить OpenSSH использовать эти старые ключи, но ИМО, ЕДИНСТВЕННЫЙ раз, когда вы должны включить устаревший протокол, - это при подключении к оборудованию, которое просто не может быть обновлено для использования более нового метода шифрования (и это оборудование, вероятно, нуждается в замене TBH) . У меня есть «умный» сетевой PDU (блок подачи питания), и он поддерживает только некоторые небезопасные шифры, поэтому у меня есть конкретное исключение в моем ssh_config для этого хоста, но я также помещаю его в отдельную VLAN, которая не разговаривает в Интернет, потому что это угроза безопасности.
dragon788
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.