Bagaimana mengatasi "sign_and_send_pubkey: penandatanganan gagal: operasi ditolak agen"?

Mengonfigurasi tetesan Digital Ocean baru dengan kunci SSH. Ketika saya menjalankan ssh-copy-idinilah yang saya dapatkan:

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.

Namun, ketika saya mencoba melakukan ssh, ini terjadi:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Saat memasukkan kata sandi, saya masuk dengan baik, tetapi ini tentu saja mengalahkan tujuan pembuatan kunci SSH di tempat pertama. Saya memutuskan untuk melihat sisi server ssh-agent dan inilah yang saya dapatkan:

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 juga berisi entri kunci ssh-rsa, tetapi find -name "keynamehere"tidak mengembalikan apa-apa.

Jalankan ssh-adddi mesin klien, yang akan menambahkan kunci SSH ke agen.

Konfirmasikan dengan ssh-add -l(sekali lagi pada klien) bahwa itu memang ditambahkan.

Setelah memutakhirkan Fedora 26 menjadi 28 saya menghadapi masalah yang sama. Dan log berikut hilang

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

ISU:

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

pesan kesalahan tidak menunjukkan masalah sebenarnya. Masalah diselesaikan oleh

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

Saya mengalami masalah yang sama di Linux Ubuntu 18 . Setelah pembaruan dari Ubuntu 17.10 , setiap perintah git akan menampilkan pesan itu.

Cara mengatasinya adalah dengan memastikan bahwa Anda memiliki izin yang benar pada id_rsadan id_rsa.pub.

Periksa nomor chmod saat ini dengan menggunakan stat --format '%a' <file>. Ini harus 600 untuk id_rsa dan 644 untuk id_rsa.pub.

Untuk mengubah izin pada penggunaan file

chmod 600 id_rsa
chmod 644 id_rsa.pub

Itu memecahkan masalah saya dengan pembaruan.

Jalankan perintah di bawah ini untuk mengatasi masalah ini.

Itu berhasil untuk saya.

chmod 600 ~/.ssh/id_rsa

Saya mengalami kesalahan saat menggunakan gpg-agent sebagai ssh-agent saya dan menggunakan subkunci gpg sebagai kunci ssh saya https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Saya menduga bahwa masalah ini disebabkan oleh entri pin tty yang tidak valid untuk gpg yang disebabkan oleh perintah tidur + kunci saya yang digunakan dalam konfigurasi sway saya

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

atau hanya tidur / tunda

Atur ulang tty entri pin untuk memperbaiki masalah

gpg-connect-agent updatestartuptty /bye > /dev/null

dan perbaikan untuk perintah 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'"

Untuk kesalahan ini:

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

Verifikasi atau tambahkan lagi kunci publik di akun Github> profil> ssh.

Saya menyelesaikannya seperti ini:

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

Terima kasih.

Mungkin ada berbagai alasan untuk mendapatkan kesalahan SSH:

sign_and_send_pubkey: penandatanganan gagal: agen menolak operasi

Beberapa di antaranya mungkin terkait dengan masalah yang disorot oleh jawaban lain (lihat utas jawaban ini), beberapa di antaranya mungkin disembunyikan dan karenanya memerlukan penyelidikan lebih dekat.

Dalam kasus saya, saya mendapat pesan kesalahan berikut:

sign_and_send_pubkey: penandatanganan gagal: agen menolak operasi

pengguna@website.domain.com: Izin ditolak (publickey, gssapi-keyex, gssapi-with-mic)

Satu-satunya cara untuk menemukan masalah sebenarnya adalah dengan mengaktifkan opsi -v verbose yang menghasilkan banyak info debugging:

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

Harap dicatat bahwa baris mengatakan key_load_public: No such file or directory mengacu pada baris berikutnya dan bukan baris sebelumnya.

Jadi yang sebenarnya SSH katakan adalah bahwa ia tidak dapat menemukan file kunci publik yang diberi nama id_rsa.website.domain.com-certdan itu tampaknya menjadi masalah dalam kasus saya karena file kunci publik saya tidak berisi -certsufiks.

Singkat cerita: perbaikan dalam kasus saya hanya untuk memastikan bahwa file kunci publik dinamai seperti yang diharapkan. Saya tidak pernah bisa menduga itu tanpa men-debug koneksi.

Intinya adalah GUNAKAN MODE VERBOSE SSH (opsi -v) untuk mencari tahu apa yang salah, mungkin ada berbagai alasan, tidak ada yang dapat ditemukan di utas ini / lainnya.

Ini seharusnya lebih merupakan pertanyaan SuperUser.

Benar, saya memiliki kesalahan yang sama persis di dalam MacOSX SourceTree, namun, di dalam terminal iTerm2, semuanya berfungsi dengan baik.

Namun, masalahnya sepertinya saya punya dua ssh-agent operasi; (

Yang pertama /usr/bin/ssh-agent(alias MacOSX) dan kemudian juga HomeBrew diinstal /usr/local/bin/ssh-agentberjalan.

Menjalankan terminal dari SourceTree, memungkinkan saya untuk melihat perbedaannya SSH_AUTH_SOCK, dengan menggunakan lsofsaya menemukan dua ssh-agents yang berbeda dan kemudian saya dapat memuat kunci (menggunakan ssh-add) ke dalam default sistem ssh-agent(yaitu /usr/bin/ssh-agent), SourceTree bekerja kembali.

Iya. Jalankan ssh-add di mesin klien. Kemudian ulangi perintah ssh-copy-id userserver@012.345.67.89

Bagi saya masalahnya adalah salah salin / tempel kunci publik ke Gitlab. Salinan menghasilkan pengembalian ekstra. Pastikan apa yang Anda tempelkan adalah kunci satu baris.

Saya mendapat sign_and_send_pubkey: signing failed: agent refused operationkesalahan juga. Tapi dalam kasus saya masalahnya adalah pinentryjalan yang salah .

Dalam properti saya ${HOME}/.gnupg/gpg-agent.conf, pinentry-programproperti itu menunjuk ke jalan masuk yang lama. Memperbaiki jalur di sana dan memulai ulang gpg-agentmemperbaikinya untuk saya.

Saya menemukannya dengan mengikuti log dengan journalctl -f. Disana garis log seperti berikut ini mengandung path yang salah:

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

Saya perlu berbagi, karena saya menghabiskan terlalu banyak waktu untuk mencari solusi

Inilah solusinya: https://unix.stackexchange.com/a/351742/215375

Saya menggunakan perintah ini:

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

gnome-keyring tidak mendukung kunci yang dihasilkan.

Menghapus -oargumen memecahkan masalah.

Dalam kasus saya, masalahnya adalah bahwa GNOME keyring memiliki frasa sandi yang tidak valid untuk kunci ssh yang akan digunakan. Setelah menghabiskan banyak waktu untuk memecahkan masalah ini, saya berlari seahorsedan menemukan entri untuk menampung string kosong. Saya hanya bisa menebak bahwa itu disebabkan oleh kesalahan ketik frasa sandi pada penggunaan pertama beberapa waktu sebelumnya, dan kemudian mungkin membatalkan pemohon atau lebih untuk kembali ke baris perintah. Memperbarui entri dengan frasa sandi yang benar segera menyelesaikan masalah. Menghapus entri itu (dari keyring "login") dan memasukkan kembali kata sandi pada prompt pertama itu (dan mencentang kotak centang yang sesuai) memecahkan masalah ini juga. Sekarang agen mendapatkan kata sandi yang benar dari kunci yang dibuka pada login keyring bernama "login" dan tidak lagi meminta kata sandi atau "menolak operasi". Tentu saja YMMV.

Apa yang berhasil di sini: pada klien

1) ssh-add

2) ssh-copy-id pengguna @ server

Kunci telah dibuat beberapa waktu yang lalu dengan biasa "ssh-keygen -t rsa" Saya menukar pesan kesalahan karena saya menyalin kunci publik ssh saya dari klien ke server (dengan ssh-id-copy) tanpa menjalankan ssh-add terlebih dahulu, karena saya salah berasumsi bahwa saya telah menambahkannya beberapa waktu sebelumnya.

catatan singkat untuk mereka yang baru saja meningkatkan ke versi ssh "modern" [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 Sep 2019] - disertakan dengan fedora 31, tampaknya tidak lagi menerima kunci DSA SHA256 lama (milik saya tertanggal 2006!) - membuat kunci rsa baru, publik ditambahkan ke otorisasi, pribadi pada klien, dan semuanya bekerja dengan sempurna.

terima kasih atas saran sebelumnya, terutama ssh -v telah sangat berguna