Saya baru saja memutakhirkan Sistem Ubuntu saya dari 15.10 ke 16.04 dengan sepenuhnya menghapus partisi Ubuntu 15 dari sistem saya.

Setelah menginstal Ubuntu 16.04 saya membuat kembali kunci ssh saya karena saya lupa untuk mencadangkannya, tetapi setiap kali saya mencoba untuk menggunakan ssh saya mendapatkan sign_and_send_pubkey: signing failed: agent refused operationini sedikit mengganggu karena memungkinkan saya melalui ke server ssh saya, tetapi git menolak untuk mendorong kode menggunakan ssh.

Saya sudah mendorong tombol ke server dengan menggunakan ssh-copy-id.

Server yang saya hubungkan adalah Server Ubuntu 16.04 yang ditingkatkan melalui do-release-upgradeperintah. Bantuan apa pun akan sangat dihargai.

Sepertinya ssh-agentsudah berjalan tetapi tidak dapat menemukan kunci yang terpasang. Untuk mengatasi ini tambahkan identitas kunci pribadi ke agen otentikasi seperti:

ssh-add

Kemudian Anda bisa sshmasuk ke server Anda.

selain itu, Anda dapat melihat daftar sidik jari dari semua identitas yang saat ini ditambahkan oleh:

ssh-add -l

Solusi Sederhana

Saya memiliki masalah yang sama di Ubuntu 18.04. Itu semua tentang izin kunci pribadi sisi klien .

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

Izin file terlalu terbuka (0644).

Perintah berikut menyelesaikannya:

chmod 600 ~/.ssh/id_rsa

Saya memiliki masalah yang sama (gejala yang sama)

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

... tetapi solusinya berbeda.

Masalahnya berasal dari penggunaan GNOME-KEYRING. Posting yang merujuk pada solusi dapat dibaca di sini .

Pendeknya:

1. Deteksi masalah dengan menambahkan SSH_AUTH_SOCK = 0 di depan perintah ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
2. Jika berhasil terhubung. Buka aplikasi StartUp Application (dengan menggunakan fungsi pencarian Desktop misalnya) dan nonaktifkan penggunaan keyn gnome.
3. Mulai ulang

Halaman ini memberikan perincian lain jika ada masalah serupa dengan solusi yang berbeda.

Saya mendapatkan sign_and_send_pubkey: signing failed: agent refused operationketika masuk ke beberapa server, membaca jawaban VonC pada Stack Overflow untuk informasi lebih lanjut tentang bug terkait, solusi bagi saya adalah menghapus gnome-keyring, menghapus identitas dari ssh-agent dan reboot.

sudo apt-get autoremove gnome-keyring
ssh-add -D

Kemudian semua kunci saya mulai bekerja dengan sempurna.

MEMPERBARUI:

Solusi sementara tanpa menghapus instalan keyring

Jika Anda ingin menjaga gnome-keyring dan Anda memiliki agent refused operationkesalahan, gunakan:

eval `ssh-agent -s`
ssh-add

atau gunakan SSH_AUTH_SOCK=0 ssh your-server

Solusi permanen tanpa menghapus instalan keyring

Jika Anda bisa, gnome-keyring kompatibel dengan kunci RSA 4096 bit, jadi buat kunci baru dengan:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

Unggah kunci publik ke server

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

Tambahkan kunci ssh ke agen

ssh-add ~/.ssh/your-key-name

Ini seharusnya berfungsi tanpa peretasan tambahan dan gnome-keyring dapat tetap diinstal.

(-C [nama pengguna] adalah opsional, tetapi diperlukan oleh penyedia seperti Google Cloud)

Setelah memutakhirkan ke Ubuntu 18.04 saya mendapat kesalahan yang sama sign_and_send_pubkey: signing failed: agent refused operation. Ternyata itu disebabkan oleh izin kunci ssh yang terlalu terbuka. Perintah berikut memperbaiki masalah untuk saya chmod 600 .ssh/id_rsa

Di sistem saya (juga Ubuntu 16.04, mencoba terhubung ke github), saya punya file id_ed25519 di folder .ssh saya yang membuat ssh-addgagal:

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

Setelah menghapus file ~/.ssh/id_ed25519*(tidak membutuhkannya lagi, itu dari tes sebelumnya) semuanya berjalan baik lagi.

Terjadi pada saya karena kunci pribadi saya memiliki kata sandi. Harus menjalankan ssh-adddan kemudian meminta kata sandi dan ditambahkan dengan benar. Namun, sekarang tidak meminta kata sandi saya ketika ssh'ing ke mesin.

Saya baru saja menginstal Ubuntu16.04 dan saya mengalami masalah serupa. Ketika saya mencoba mengkloning repositori saya dari Github setelah saya menyalin kunci publik saya ke github (sesuai petunjuk di github.com ) dan setelah melakukan pemeriksaan berikut ( direkomendasikan di github.com ):

ssh -T git@github.com

Saya disambut oleh yang berikut ini:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

Untuk memperbaikinya dengan cepat, tanpa menghapus apa pun atau mengubah konfigurasi startup saya, saya hanya mengetik yang berikut ini di terminal:

killall gnome-keyring-daemon

Kemudian klon bekerja. Saya kemudian memulai lagi daemon yang berhenti dengan mengetik:

gnome-keyring-daemon

Kemudian, untuk mengubah keadaan secara lebih permanen, saya mengikuti saran di sini

Setelah memutakhirkan Fedora 26 hingga 28, saya menghadapi masalah yang sama. Dan tidak ada file log

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:

pesan kesalahan tidak menunjukkan masalah yang sebenarnya. Masalah diselesaikan oleh

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

Menambahkan komentar karena saya memiliki masalah yang sama dengan kunci ed25519. Masalahnya memang gnome-keyring. Untuk memperbaiki ini saya lakukan hal berikut:

• Hapus-ssh-key-agent (gnome-keyring) di "aplikasi startup"
• Membunuh ssh-agent dan gnome agent: (killall ssh-agent; killall gnome-keyring-daemon)
• Memulai kembali daemon: (eval ssh-agent -s)
• Tambahkan kunci Anda: $ ssh-add id_ed25519 Masukkan frasa sandi untuk id_ed25519: Identitas ditambahkan: id_ed25519
• Keuntungan!!

Ini akhir tahun 2018, dan bug ini, atau variasi dari itu, masih mengganggu Xubuntu 16.04, dan lebih dari kemungkinan rasa Xenial lainnya. Saya tidak akan terkejut jika ada di 18,04 juga! Sudah ada dalam beberapa bentuk sejak 2009, dan Karmic Koala. Telah memengaruhi Redhat, Debian, dan Ubuntu. Jangan mengambil kata saya untuk itu, lihat bugtrackers publik:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

Dan pada bug itu, Anda juga menemukan daftar 3 lainnya:

Referensi:

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

Dalam kasus saya, gejala yang paling jelas adalah ketidakmampuan untuk menggunakan kunci ssh dengan frasa sandi. Ini mungkin mempengaruhi yang tanpa, karena kerusakan mencegah kunci ssh dari memuat sama sekali! Dan saya tidak punya masalah izin, itu semua gnome-keyring. Kunci saya (ya ditolak beberapa, untuk server SSH yang berbeda!) Semuanya 600 (untuk pemilik, tidak ada untuk grup atau lainnya) sebagaimana dinyatakan dalam banyak jawaban tentang itu. Jadi tidak ada yang bisa saya ubah di sana.

Di Xubuntu, ada cara untuk menonaktifkan item startup. Biasanya juga dimungkinkan di Unity / Gnome / KDE, tapi saya belum menginstalnya, jadi tidak bisa memberikan langkah-langkah spesifik. Tidak yakin dengan desktop lain. Daripada menonaktifkan agen SSH, agen GPG, dan item lain dari Gnome yang menyebabkan ini, dan bug terkait lainnya, saya mematikan semua item startup Gnome. Mungkin berlebihan atau bukan pilihan bagi sebagian orang, tetapi SSH kembali bekerja dengan sempurna pada reboot berikutnya!

1. Buka Menu Utama Kumis -> Pengaturan -> Sesi dan Startup.
2. Klik tab Advanced, yang terakhir di sebelah kanan.
3. Hapus centang (matikan) Luncurkan Layanan Gnome saat startup.
4. Tutup dan reboot. Logout mungkin juga melakukannya, tetapi reboot harus dipastikan.

Cuplikan layar GUI yang dijelaskan di atas:

Jadi, karena saya memberikan perbaikan saya di atas, saya berharap seseorang akan memperbaikinya.

Ubuntu terbukti gagal memencetnya untuk selamanya, karena ada banyak tiket untuk beberapa rilis yang mengklaim sudah diperbaiki, dan banyak lagi yang mengatakan "regresi", sudah kembali.

Debian mungkin ingin menyepak (mencuci tangan mereka) karena itu bukan mereka, hulu adalah Gnome.

Redhat mungkin hanya memiliki perbaikan yang tersedia untuk pelanggan yang membayar. Karena, secara historis, Redhat adalah perusahaan tunggal terbesar dari pengembang Gnome berbayar, yang pada awalnya terlihat murah hati. Sampai Anda menyadari itu berarti mereka memiliki insentif keuangan untuk tidak pernah melakukan perbaikan seperti ini ke dalam versi gratis, untuk tetap menjual langganan Redhat.

Gnome mungkin adalah orang-orang yang dapat memperbaikinya dengan upstream termudah, dan yang lain dapat menguji dan mengemasnya, tanpa menulis satu baris kode pun. Tetapi tiket yang saya baca mengatakan paket itu telah merana selama bertahun-tahun tanpa pengelola resmi! Dan dua orang yang secara sukarela melakukannya sekarang (terima kasih) hampir sama sibuknya merancang pengganti. Mengapa tidak memperbaiki ban kempes bahkan jika itu membutuhkan waktu satu tahun (sudah satu dekade!) Daripada menciptakan kembali roda terlebih dahulu ?!

ssh-add

bekerja untukku. Tapi pastikan

ssh-agent

sedang berlari.

Dalam kasus saya, masalah ini disebabkan oleh GNOME Keyring. Untuk menonaktifkan kemampuan SSH gnome-keyring tanpa langsung menghapusnya (yang merusak banyak hal), ikuti petunjuk ini :

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

dan mulai kembali sesi. Sekarang Anda dapat menjalankan ssh-agent tanpa campur tangan gnome-keyring.

Saya mencoba beberapa hal, antara lain ssh-add, mengatur ulang SSH (menghapus .ssh / di server, dan semacamnya, tetapi tidak berhasil. Jadi ternyata saya hanya harus tidur selama satu malam. Itu membantu! Mengapa! "Saya kira ssh-agent yang berjalan di server memiliki sesuatu dalam cache-nya yang disegarkan malam itu dengan nilai-nilai sekarang yang tepat. Bagaimanapun, sekarang berfungsi seperti pesona. Untuk menyelesaikannya, ia melakukan ini (Ubuntu 16.04 di localhost, 14,04 di server).

# 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! :)

Saya akhirnya menjatuhkan file host saya yang dikenal dan berhasil. Harus memasukkan kata sandi lagi, tetapi akhirnya menerima kata sandi yang tepat. Itu setelah instalasi baru.

Jika menambahkan SSH_AUTH_SOCK = 0 sebelum perintah ssh membantu, maka itu adalah kesalahan keyring gnome. Kecuali solusi dan masalah yang diberikan, masalah mungkin terkait dengan frasa sandi. Jika Anda memiliki frasa sandi untuk kunci, maka gnome keyring menanyakannya saat Anda masuk pertama kali dan jika Anda memasukkan kosong karena kesalahan atau menutup jendela secara tidak terduga, gnome menganggapnya sebagai frasa sandi kosong dan mengingatnya selamanya. Tidak ada yang membantu untuk diminta lagi frasa sandi. Untuk menyelesaikan aplikasi keyring ssh terbuka dan masuk ke bagian Login di bawah kategori Kata Sandi. Temukan catatan yang sesuai untuk kunci bermasalah dan masukkan ke Properties dan masukkan frasa sandi yang benar.

Ada penyebab lain dari ini yang belum ada jawaban: format PEM untuk file kunci berhenti menjadi default untuk ssh-keygensebelum Ubuntu pindah ke gnome-keyring-daemonyang mendukung format RFC4716 baru.

Jika Anda membuat kunci baru, atau menambah / menghapus frasa sandi dari kunci Anda, itu mungkin rusak. Kuncinya adalah menggunakan ssh-keygen -m PEMsebelum operasi lain apa pun yang perlu Anda jalankan. Misalnya, Anda dapat mengonversi kembali ke format lama dengan menggunakan ssh-keygen -m PEM -pdan memasukkan frasa sandi lama sebagai frasa sandi baru (yang akan kosong tanpa frasa sandi).