Як вирішити “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 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 / autori_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-агента як мого ssh-агента та використання підрозділу gpg як мого ключа ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Я підозрюю, що проблема була спричинена тим, що в моєму конфігураційному настроюванні, що використовується в моєму режимі сну + блокування, недійсний запис tty для gpg, викликаний моєю командою сну + блокування

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

і виправлення для мого сну режиму сну + блокування команди:

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> профіль> 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), щоб з’ясувати, що не так. Можуть бути різні причини, жодна з яких не може бути знайдена в цьому / іншому потоці.

Це має бути скоріше питання SuperUser.

Правильно, я маю таку саму помилку всередині MacOSX SourceTree, однак, усередині терміналу iTerm2 все працює просто денді.

Однак проблема, здавалося, полягає в тому, що у мене два ssh-agent біги; (

Спочатку був /usr/bin/ssh-agent(він же MacOSX), а потім також встановлений HomeBrew /usr/local/bin/ssh-agent.

Запустивши термінал від 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і знайшов запис, щоб утримувати порожній рядок. Я можу лише здогадуватися, що це було спричинено помилковим введенням парольної фрази спочатку за допомогою деякого часу раніше, а потім, ймовірно, скасування запитувача або близько того, щоб повернутися до командного рядка. Оновлення запису правильною парольною фразою негайно вирішило проблему. Видалення цього запису (з ключового входу "login") та повторне введення парольної фрази під час першого запиту (та встановлення відповідного прапорця) також вирішує це. Тепер агент отримує правильну парольну фразу з розблокованої при вході в обліковий запис під назвою "login" і більше не запитує парольну фразу, ані "відмовляється від роботи". Звичайно YMMV.

Що тут працювало: на клієнта

1) ssh-add

2) ssh-copy-id user @ server

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

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

дякую за попередні пропозиції, особливо ssh -v було дуже корисно