SSH batal dengan terlalu banyak kegagalan otentikasi

26

Saya mencoba menjalankan skrip provisi sederhana ini tetapi saya mengalami kesalahan saat menjalankan vagrant updan kemudian vagrant provisionmemerintahkan.

Saya membaca bahwa saya perlu membuat /etc/ansible/hostsfile yang telah saya lakukan, mengisinya dengan:

[vagrant]
192.168.222.111

Konfigurasi SSH saya (beberapa detail dihapus):

Host default
HostName 127.0.0.1
User vagrant
Port 2222
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile /Users/ashleyconnor/.vagrant.d/insecure_private_key
IdentitiesOnly yes
LogLevel FATAL

Host            server
HostName        XXX.XXX.XXX.XXX
User            ash
PreferredAuthentications publickey
IdentityFile    ~/.ssh/ash_ovh

Host            deployer
HostName        XXX.XXX.XXX.XXX
User            deployer
PreferredAuthentications publickey
IdentityFile    ~/.ssh/deployer_ovh

Host            bitbucket.org
PreferredAuthentications publickey
IdentityFile    ~/.ssh/bitbucket

Host            github.com
PreferredAuthentications publickey
IdentityFile    ~/.ssh/github

Host            staging
HostName        192.168.56.10
User            deployer
PreferredAuthentications publickey
IdentityFile    ~/.ssh/id_rsa

Output SSH yang saya terima tampaknya berputar melalui semua kunci saya:

<192.168.222.111> ESTABLISH CONNECTION FOR USER: vagrant
<192.168.222.111> REMOTE_MODULE setup
<192.168.222.111> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/Users/ashleyconnor/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'IdentityFile=/Users/ashleyconnor/.vagrant.d/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', '192.168.222.111', "/bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061 && echo $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061'"]
fatal: [192.168.222.111] => SSH encountered an unknown error. The output was:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/ashleyconnor/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/ashleyconnor/.ansible/cp/ansible-ssh-192.168.222.111-22-vagrant" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.222.111 [192.168.222.111] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug3: timeout: 10000 ms remain after connect
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/ashleyconnor/.vagrant.d/insecure_private_key" as a RSA1 public key
debug1: identity file /Users/ashleyconnor/.vagrant.d/insecure_private_key type -1
debug1: identity file /Users/ashleyconnor/.vagrant.d/insecure_private_key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.222.111" from file "/Users/ashleyconnor/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/ashleyconnor/.ssh/known_hosts:20
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],zlib,none
debug2: kex_parse_kexinit: [email protected],zlib,none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 [email protected]
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 [email protected]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 527/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 50:db:75:ba:11:2f:43:c9:ab:14:40:6d:7f:a1:ee:e3
debug3: load_hostkeys: loading entries for host "192.168.222.111" from file "/Users/ashleyconnor/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/ashleyconnor/.ssh/known_hosts:20
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.222.111' is known and matches the RSA host key.
debug1: Found key in /Users/ashleyconnor/.ssh/known_hosts:20
debug2: bits set: 511/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/ashleyconnor/.ssh/id_rsa (0x7fc212600540),
debug2: key: /Users/ashleyconnor/.ssh/bitbucket (0x7fc212600730),
debug2: key: /Users/ashleyconnor/.ssh/deployer (0x7fc212600a00),
debug2: key: /Users/ashleyconnor/.ssh/github (0x7fc212600c80),
debug2: key: /Users/ashleyconnor/.ssh/ash_ovh (0x7fc212601010),
debug2: key: /Users/ashleyconnor/.ssh/deployer_ovh (0x7fc2126011e0),
debug2: key: /Users/ashleyconnor/.vagrant.d/insecure_private_key (0x0), explicit
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,gssapi-keyex,hostbased,publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred: ,gssapi-keyex,hostbased,publickey
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/bitbucket
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/deployer
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/github
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/ash_ovh
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/deployer_ovh
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Received disconnect from 192.168.222.111: 2: Too many authentication failures for vagrant

The vagrant sshperintah bekerja dengan baik.

Abu
sumber
Kemungkinan Duplikat: serverfault.com/questions/139870/…
Henk Langeveld
Sedikit berbeda. Vagrant menyuntikkan kunci itu ketika Anda menjalankan vagrant sshdan pertanyaan ini hanya melibatkan otentikasi tanpa kunci.
Ash
2
Menambahkan catatan untuk orang lain Googling ini Switch Cisco Nexus mengalami masalah yang sama. Diselesaikan dengan cara yang sama seperti yang ditunjukkan oleh @HenkLangeveld di bawah ini:IdentitiesOnly=yes
Brett Lykins

Jawaban:

37

Menurut ssh-config(5), ssh akan selalu mencoba semua kunci yang dikenal oleh agen di samping setiap File Identitas:

 IdentitiesOnly
         Specifies that ssh(1) should only use the authentication identity files
         configured in the ssh_config files, even if ssh-agent(1) offers more
         identities.  The argument to this keyword must be “yes” or “no”.  This
         option is intended for situations where ssh-agent offers many different
         identities.  The default is “no”.

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentication
         identity is read.  The default is ~/.ssh/identity for protocol version 1,
         and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol
         version 2.  Additionally, any identities represented by the  
         authentication agent will be used for authentication.  ssh(1) will try
         to load certificate information from the filename obtained by
         appending -cert.pub to the path of a specified IdentityFile.

Untuk mencegah hal ini, seseorang harus menentukan IdentitiesOnly=yesselain kunci pribadi yang disediakan secara eksplisit.

Misalnya, jalankan sshperintah di bawah ini:

$ ssh -i /home/henk/.vagrant.d/insecure_private_key \
  [email protected] echo ok

menghasilkan:

Received disconnect from 192.168.222.111: 2: Too many authentication 
failures for vagrant

Namun, menjalankan sshperintah yang sama dan, di samping itu, menetapkan IdentitiesOnly=yes:

$ ssh -o IdentitiesOnly=yes \
  -i /home/henk/.vagrant.d/insecure_private_key [email protected] echo ok

menghasilkan:

ok
Henk Langeveld
sumber
Sunting: Menghapus asumsi yang salah tentang keharusan menambahkan kunci gelandangan ke agen. Ini mengurangi jawaban pada esensinya. Mari kita lihat apakah kita dapat menemukan duplikat ...
Henk Langeveld
3
Terima kasih untuk penjelasannya! Saat menggunakan .ssh/configfile, sintaksisnya ada IdentitiesOnly yesdi bagian yang sesuai Host.
davil
Benar, ssh -o Option=Valuemenjadi Option Valuedalam file konfigurasi.
Henk Langeveld
maafkan jika pertanyaannya terlalu mendasar tetapi, apakah "IdentitiesOnly = yes" di sisi server atau argumen yang dilewatkan dari klien? Sepertinya yang kedua ..
RollRoll
@ThePoet Memang, menyebutkannya sebagai sshopsi klien.
Henk Langeveld
8

Jadi saya punya 5 kunci di saya ssh-agentdan meskipun opsi eksplisit untuk menggunakan kunci ssh gelran itu masih bersikeras perulangan melalui kunci di agen saya sebelum mencapai max_tries nyaman sebelum sampai ke kunci yang tepat.

Untuk memeriksa Anda memiliki masalah ini: Jalankan ssh-add -l- jika daftar ini> 5 Anda harus menghapus kunci atau menonaktifkan agen.

Untuk memperbaikinya: Jalankan di ssh-add -d ~/.ssh/Xmana Xkunci yang ingin Anda hapus.

Abu
sumber
Setelah menginstal repo mazer-rackham dan dengan informasi ini saya dapat mereproduksi masalah Anda dan saya telah menambahkan alternatif: Pastikan bahwa kunci gelandangan diketahui oleh agen.
Henk Langeveld
Saya menambahkannya ke agen tetapi masih harus menghapus kunci. Mungkin pesanan yang Anda tambahkan ke agen penting? EDIT: Baca saja hasil edit Anda.
Ash
Saya memiliki masalah yang sama, tetapi saya tidak mengerti bagaimana Anda memperbaikinya? Saya tidak dapat menghapus salah satu tombol dari ~/.ssh/folder saya , saya perlu
rubo77
Anda tidak menghapus kunci dari ~.sshfolder Anda - Anda menghapus kunci dari ssh-agent daemon. Anda selalu dapat menambahkannya kembali nanti. Lihat di sini untuk info lebih lanjut.
Ash
4

Setelah saya mencoba semua saran di sini tanpa hasil, saya menyadari bahwa masalah saya adalah metode otentikasi baru (GSSAPI), yang selalu gagal.

Saya memecahkan ini dengan mengedit ~/.ssh/configfile:

Host *
  GSSAPIAuthentication no

Semoga ini bisa membantu seseorang juga.

Peter
sumber
Ini tampaknya setidaknya membuat satu slot! Pengaturan saya dengan 5 kunci melalui ssh-agent berfungsi lagi. Saya kira itu akan gagal dengan 6 kunci, ...
Robert Siemer
2

Agen ssh Anda memiliki lebih banyak kunci daripada yang diizinkan oleh server ssh untuk melakukan otentikasi ("MaxAuthTries", default: 6).

Perhatikan bahwa beberapa ssh-agent, khususnya GNOME Keyring, memuat ulang semua kunci secara otomatis di ~ / .ssh, dan bahwa kunci-kunci ini tidak dapat dibongkar dengan "ssh-add - [dD]".

Berikut ini beberapa solusinya:

  • Anda telah mengkonfigurasi kunci yang benar di ~ / .ssh / config Anda, jadi Anda tidak memerlukan agen tersebut. Buat klien mengabaikan agen, mis. unset SSH_AUTH_SOCKAtau gunakan "IdentitiesOnly = yes" seperti yang disarankan @ henk-langeveld
  • Pindahkan beberapa kunci dari ~ / .ssh (subdir seperti ~ / .ssh / noauto juga berfungsi) untuk mencegahnya dimuat secara otomatis. Anda masih dapat ssh-menambahkannya secara manual jika Anda membutuhkannya.
  • Tingkatkan "MaxAuthTries" di sisi server, jumlah upaya otentikasi yang diizinkan
Nils Toedtmann
sumber
2

Untuk mencegah hal ini, kita dapat ssh menggunakan -o 'IdentitiesOnly yes'misssh -i privateKey -o 'IdentitiesOnly yes' user@host

sebagai alternatif, kita dapat menambahkan baris berikut ke file ~ / .ssh / config

Host *
IdentitiesOnly yes
Jasodeep Chatterjee
sumber
1

Untuk menghubungkan server menggunakan perintah perbaikan cepat:

ssh -o IdentitiesOnly=yes -i ~/.ssh/private_key_or_pem_file_name server_user_name@ip_OR_hostname echo ok

Recommended Way disebutkan di bawah ini:

Tetapi jika Anda memiliki capistrano receipes atau perangkat lunak lain yang menghubungkan server ssh Anda, maka Anda harus memperbaikinya dengan cara yang benar seperti yang disebutkan di bawah ini:

Dalam file ~ / .ssh / config sebutkan opsi "IdentitiesOnly yes" di konfigurasi server Anda

Host server_domain_OR_ip server_name_your_choice
    User server_user_name
    Hostname server_domain_OR_ip
    RSAAuthentication yes
    Compression yes
    IdentityFile ~/.ssh/private_key_OR_pem_file
    IdentitiesOnly yes
    Port 22

private_key_OR_pem_file: Dalam kasus ekstensi pem file menyebutkan juga ".pem"

Taimoor Changaiz
sumber
1

Saya mengalami kesalahan yang sama saat mencoba menjalankan buku pedoman yang mungkin. Saya akhirnya menyediakan opsi IdentitiesOnly ssh menggunakan --ssh-extra-args:

ansible-playbook -i ../.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml --ssh-extra-args="-o IdentitiesOnly=yes"
strictk3v
sumber
0

Pesan utamanya adalah

Received disconnect from 192.168.222.111: 2: 
    Too many authentication failures for vagrant

Anda menyalin output ssh-config gelandangan sebagai host default ke .ssh/configtetapi ini dilewati karena memiliki parameter yang bertentangan (hostname, port). Tanpa entri yang cocok, ssh hanya akan mencoba semua kunci yang dapat ditemukan.

Uji lagi upaya ssh dengan -iopsi

$ ssh -i $HOME/.vagrant.d/insecure_private_key [email protected] echo ok

Saya percaya ini adalah bagaimana Anda akan menentukan ini di Inventaris Ansible:

[vagrant]
192.168.222.111 ansible_ssh_private_key_file=/.../.vagrant.d/insecure_private_key

Menyingkat jalur untuk keterbacaan


Jawaban asli:

Bandingkan keluaran vagrant ssh-configdengan entri gelandangan di blog Anda .ssh/config. Pastikan jalur kunci privat sama persis.

Pastikan juga bahwa keyfile tidak dapat diakses oleh akun lain. Kita semua tahu apa kunci itu, tetapi SSH tidak tahu hal ini adalah pengetahuan umum, dan mencoba melindungi kita dari menggunakan kunci yang mungkin dikompromikan.

Henk Langeveld
sumber
Saya awalnya menyalin konfigurasi dari vagrant ssh-configtetapi saya memeriksa lagi dan itu identik. Saya juga bisa cat /Users/ashleyconnor/.vagrant.d/insecure_private_keydan memiliki izin yang memadai.
Ash
Pastikan tidak ada orang lain yang bisa membaca atau menulis file.
Henk Langeveld
1
Hanya saya yang memiliki izin rw. Tidak beruntung pada saran lain, saya mencoba berlari ssh -i $HOME/.vagrant.d/insecure_private_key -l vagrant 192.168.222.111masih mendapatkanReceived disconnect from 192.168.123.123: 2: Too many authentication failures for vagrant
Ash
Apakah host jarak jauh memiliki pengguna vagrant?
Henk Langeveld
Iya nih. Ketika saya menjalankannya vagrant sshterhubung sebagai gelandangan pengguna
Ash