Mengonfigurasi tetesan Digital Ocean baru dengan kunci SSH. Ketika saya menjalankan ssh-copy-id
inilah yang saya dapatkan:
ssh-copy-id [email protected]
/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
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
Namun, ketika saya mencoba melakukan ssh, ini terjadi:
ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'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:
[email protected]:~# eval `ssh-agent -s`
Agent pid 5715
[email protected]:~# 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.
ssh
remote-access
digital-ocean
ssh-keys
pengguna968270
sumber
sumber
gpg-agent
untuk fungsionalitas SSH. Saya sudah memilikienable-ssh-support
digpg-agent.conf
tetapi masih pesan kesalahan yang sama. Saya telah menemukan di milis untuk menjalankan inigpg-connect-agent updatestartuptty /bye
:: bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394ssh-add
harus dipanggil agarssh-agent
mengetahui kunci pribadi baru (per linux.die.net/man/1/ssh-agent ).ssh-add
berhasil! Terima kasih.Setelah memutakhirkan Fedora 26 menjadi 28 saya menghadapi masalah yang sama. Dan log berikut hilang
ISU:
pesan kesalahan tidak menunjukkan masalah sebenarnya. Masalah diselesaikan oleh
sumber
.ssh/
tidak memiliki izin yang diperlukan karena saya telah membuatnya sendiri secara manual.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_rsa
danid_rsa.pub
.Periksa nomor chmod saat ini dengan menggunakan
stat --format '%a' <file>
. Ini harus 600 untukid_rsa
dan 644 untukid_rsa.pub
.Untuk mengubah izin pada penggunaan file
Itu memecahkan masalah saya dengan pembaruan.
sumber
id_rsa.pub
digunakan dalam proses otentikasi klien?~/.ssh
:chmod 600 id_*
Jalankan perintah di bawah ini untuk mengatasi masalah ini.
Itu berhasil untuk saya.
sumber
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'"
sumber
gpg-connect-agent updaterstartuptty /bye > /dev/null
~ / .zshrc saya, menghapus komentar baris ini memecahkan masalah saya.Untuk kesalahan ini:
Saya menyelesaikannya seperti ini:
Terima kasih.
sumber
Mungkin ada berbagai alasan untuk mendapatkan kesalahan SSH:
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:
Satu-satunya cara untuk menemukan masalah sebenarnya adalah dengan mengaktifkan opsi -v verbose yang menghasilkan banyak info debugging:
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-cert
dan itu tampaknya menjadi masalah dalam kasus saya karena file kunci publik saya tidak berisi-cert
sufiks.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.
sumber
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-agent
berjalan.Menjalankan terminal dari SourceTree, memungkinkan saya untuk melihat perbedaannya
SSH_AUTH_SOCK
, dengan menggunakanlsof
saya menemukan duassh-agent
s yang berbeda dan kemudian saya dapat memuat kunci (menggunakanssh-add
) ke dalam default sistemssh-agent
(yaitu/usr/bin/ssh-agent
), SourceTree bekerja kembali.sumber
Iya. Jalankan ssh-add di mesin klien. Kemudian ulangi perintah ssh-copy-id [email protected]
sumber
Bagi saya masalahnya adalah salah salin / tempel kunci publik ke Gitlab. Salinan menghasilkan pengembalian ekstra. Pastikan apa yang Anda tempelkan adalah kunci satu baris.
sumber
Saya mendapat
sign_and_send_pubkey: signing failed: agent refused operation
kesalahan juga. Tapi dalam kasus saya masalahnya adalahpinentry
jalan yang salah .Dalam properti saya
${HOME}/.gnupg/gpg-agent.conf
,pinentry-program
properti itu menunjuk ke jalan masuk yang lama. Memperbaiki jalur di sana dan memulai ulanggpg-agent
memperbaikinya untuk saya.Saya menemukannya dengan mengikuti log dengan
journalctl -f
. Disana garis log seperti berikut ini mengandung path yang salah:sumber
Saya perlu berbagi, karena saya menghabiskan terlalu banyak waktu untuk mencari solusi
Saya menggunakan perintah ini:
gnome-keyring tidak mendukung kunci yang dihasilkan.
Menghapus
-o
argumen memecahkan masalah.sumber
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
seahorse
dan 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.sumber
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.
sumber
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
sumber