sign_and_send_pubkey: ошибка подписи: агент отказался от операции
Я также столкнулся с этой проблемой при вставке модуля в ядро. Правильно введите текущую версию ядра, перейдите в каталог cd / lib / modules / your-kernel-version-gereric / и проверьте, присутствует ли каталог сборки или нет. Если он присутствует, вы можете напрямую скомпилировать свой модуль, используя команду ниже
make -C /lib/modules/$(shell uname -r)/build M=$(PWD)
Итак, после нескольких часов бездумного гугления и помощи, проблема была обнаружена. Я генерировал свои ssh ключи с помощью ssh-keygen и добавил дополнительный аргумент "-o", который генерировал ключи в новом формате для openSSH. Проблема заключалась в том, что мой gnome-keyring не поддерживал такие ключи, поскольку ключи имели схему подписи Ed255519. Gnome-keyring не поддерживает эту схему с версии 3.20. Я вернулся к RSA и больше никаких проблем!
Многие предложения по решению этой проблемы намекают на изменение прав доступа к каталогу ~/.ssh и содержащимся в нем файлам. Подробнее об этом:https://gist.github.com/grenade/6318301
Некоторые даже предлагают ssh-add, что может не решить проблему и может быть излишним.
Попробовав оба вышеперечисленных способа, я не решил эту проблему. Вместо этого проблема заключалась в типе ключа ssh, который я генерировал.
Как упомянул @strudelj nudelj, важно проверить, поддерживается ли тип шифрования, используемый вашим открытым ключом, сервером, к которому вы подключаетесь. Например, сервер gitlab, который я пытался использовать, не поддерживал тип ключей, обычно хранящихся в ~/.ssh/id_dsa.pub
Вместо этого требовались зашифрованные ключи ed25519или rsa.
Для ed25519можно использовать:$ssh-keygen -t ed25519 -C "email@example.com"для генерации ключа
Затем $ssh -T user@serverдолжен предложить хорошую проверку, принят ли этот ключ и можно ли установить соединение.
В моем случае проблема заключалась в том, что связка ключей GNOME содержала недопустимую фразу-пароль для используемого ключа ssh. Потратив неприличное количество времени на устранение этой проблемы, я запустил seahorseи обнаружил, что запись содержит пустую строку.
Я могу только догадываться, что это было вызвано ошибкой при вводе парольной фразы при первом использовании некоторое время назад, а затем, возможно, отмене запросчика или около того, чтобы вернуться к командной строке.
Обновление записи с правильной кодовой фразой немедленно решило проблему.
Удаление этой записи (из набора ключей «вход в систему» )и повторный ввод фразы-пароля в этом первом приглашении (и установка соответствующего флажка )также решают эту проблему.
Теперь агент получает правильную фразу-пароль из разблокированного при входе набора ключей с именем «логин» и больше не запрашивает фразу-пароль и не «отказывается от операции». Конечно ЮММВ.