Я щойно оновив свою систему 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 (наприклад, використовуючи функцію пошуку Desktop) та відключіть використання gnome-keyring.
3. Перезавантажте

На сторінці надаються інші деталі у випадку подібної проблеми з іншим рішенням.

sign_and_send_pubkey: signing failed: agent refused operationКоли я входив на декілька серверів, читав відповідь VonC на "Переповнення стека" для отримання додаткової інформації про пов'язані помилки. Для мене рішенням було видалити gnome-keyring, видалити ідентичності з ssh-агента та перезавантажити.

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) у мене в папці .ssh був файл id_ed25519, який зробив 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 та gnome: (killall ssh-agent; killall gnome-keyring-demon)
• Повторно запустив демон: (eval ssh-agent -s)
• Додайте свій ключ: $ ssh-add id_ed25519 Введіть пароль для id_ed25519: Ідентифікація додана: id_ed25519
• Прибуток !!

Кінець 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. Мої ключі (так, відмовились від декількох, для різних SSH-серверів!) Дозволу були всі 600 (rw для власника, нічого для групи чи іншого), як сказано в багатьох відповідях на це. Тож я нічого там не міг змінити.

У Xubuntu є спосіб відключення елементів запуску. Зазвичай це також можливо в Unity / Gnome / KDE, але я не встановив їх, тому не можу дати конкретні кроки. Не впевнений в інших робочих столах. Замість того, щоб відключити SSH-агент, GPG-агент та інші елементи від Gnome, які спричиняють це, та інші пов’язані помилки, я вимкнув усі елементи запуску Gnome. Можливо, для деяких це може бути надмірно чи не варіантом, але SSH знову працює бездоганно при наступному перезавантаженні!

1. Відкрийте головне меню Whisker -> Налаштування -> Сесія та запуск.
2. Перейдіть на вкладку «Додатково», остання справа.
3. Зніміть прапорець (вимкнути) Launch Gnome Services при запуску.
4. Закрийте і перезавантажте. Вихід із системи може зробити це теж, але перезавантаження має бути точно.

Знімок екрана GUI, описаний вище:

Отже, оскільки я дав своє виправлення вище, сподіваюся, що хтось це виправить.

Ubuntu, очевидно, не зміг його розіграти назавжди, оскільки є багато квитків на кілька релізів, які стверджують, що це виправлено, і більше того, що кажуть "регресія", повернулося.

Debian, ймовірно, хоче пограбувати (помити їм руки), тому що це не вони, вище за течією є Gnome.

Redhat, ймовірно, має виправлення, доступне лише платним клієнтам. Тому що історично Redhat є найбільшим роботодавцем платних розробників Gnome, який є щедрим на перший погляд. Поки ви не зрозумієте, що це означає, що вони мають фінансовий стимул ніколи не ставити подібні виправлення у безкоштовні версії, щоб продовжувати продавати підписки на Redhat.

Gnome - це, мабуть, ті, хто може виправити це вгору найпростіше, а потім інші можуть тестувати та пакувати, не записуючи самі рядки коду. Але квитки, які я прочитав, кажуть, що пакет пропав роками без офіційного технічного обслуговування! А двоє людей, які добровільно роблять це зараз (дякую), майже так само зайняті розробкою заміни. Чому б не виправити рівну шину, навіть якщо це знадобиться рік (минуло десятиліття!), А не спочатку винаходити колесо ?!

ssh-add

працює для мене. Але будьте впевнені

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-агент без втручання ключів gnome.

Я спробував пару речей, серед яких ssh-add, скидання SSH (видалення .ssh / на сервері, і таке, але не пощастило. Тож виявилося, що я просто повинен був проспати це протягом однієї ночі. Це допомогло! Чому «Я думаю, що у ssh-агента, що працює на сервері, було щось у кеші, який було оновлено пізніше тієї ночі з теперішніми значеннями. Так чи інакше, він зараз працює як шарм. 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! :)

Я врешті-решт скинув відомий файл хостів, і він спрацював. Довелося знову ввести пароль, але він остаточно прийняв правильний пароль. Це було після нової установки.

Якщо додавання SSH_AUTH_SOCK = 0 перед тим, як команда ssh допоможе, то це помилка введення ключів gnome. За винятком наданих рішень та проблем, проблема може бути пов’язана із фразовою фразою. Якщо у вас є пароль для ключа, то gnome keyring запитує його при першому вході в систему, і якщо ви вводите порожнє з вини або несподівано закрийте вікно, gnome вважає його порожнім парольним словом і запам'ятовує його назавжди. Ніщо не допомагає знову запросити пароль. Щоб розв'язати додаток для відкриття ключів ssh та перейдіть до розділу Вхід у розділі Паролі. Знайдіть запис, що відповідає проблемному ключу, і введіть у Властивості та введіть правильну парольну фразу.

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

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