SSH, çok fazla kimlik doğrulama hatasından yoksun kaldı


26

Bu basit sağlama betiğini çalıştırmaya çalışıyorum ancak çalıştırırken vagrant upve sonra vagrant provisionkomutları verirken hatalarla karşılaşıyorum .

Yaptığım bir /etc/ansible/hostsdosyayı oluşturmak için gerekli olanları doldurarak okudum :

[vagrant]
192.168.222.111

SSH yapılandırmam (bazı detaylar kaldırıldı):

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

Aldığım SSH çıkışı tüm anahtarlarımdan çalkalanıyor gibi görünüyor:

<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: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,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: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit: zlib@openssh.com,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,rijndael-cbc@lysator.liu.se
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,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
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 zlib@openssh.com
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
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

vagrant sshKomut cezası çalışır.



Kısmen farklı. Vagrant koşarken anahtar olduğunu söylüyor vagrant sshve bu soru sadece anahtarsız kimlik doğrulaması içeriyordu.
Ash

2
Diğer insanlar için bir not ekleme Bu Google Googling. Cisco Nexus anahtarları da aynı sorundan muzdarip. Aşağıda @HenkLangeveld tarafından belirtildiği gibi çözüldü:IdentitiesOnly=yes
Brett

Yanıtlar:


37

Buna göre ssh-config(5), ssh her zaman Kimlik Dosyalarına ek olarak aracı tarafından bilinen tüm anahtarları da deneyecektir :

 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.

Bunu önlemek IdentitiesOnly=yesiçin, açıkça verilen özel anahtarın yanı sıra bir de belirtilmesi gerekir .

Örneğin, sshaşağıdaki komutu çalıştırmak :

$ ssh -i /home/henk/.vagrant.d/insecure_private_key \
  vagrant@192.168.222.111 echo ok

üretir:

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

Ancak, aynı sshkomutu çalıştırmak ve ek olarak, belirtmek IdentitiesOnly=yes:

$ ssh -o IdentitiesOnly=yes \
  -i /home/henk/.vagrant.d/insecure_private_key vagrant@192.168.222.111 echo ok

üretir:

ok

Düzenleme: Serseri anahtarının araca eklenmesi gerektiği konusundaki yanlış varsayım kaldırıldı. Bu, özüne cevabı azaltır. Bakalım bir kopyasını bulabilecek miyiz ...
Henk Langeveld

3
Açıklama için teşekkürler! Bir .ssh/configdosya kullanırken , sözdizimi IdentitiesOnly yesuygun Hostbölümlerdedir.
davil

Doğru, ssh -o Option=Valueolur Option Valueyapılandırma dosyasında.
Henk Langeveld

soru çok basit, ancak sunucu tarafında "IdentitiesOnly = yes" veya istemciden iletmek için bir argüman affet? İkinci gibi görünüyor ..
RollRoll

@ ThePoet Indeed, bir sshmüşteri seçeneği olarak belirtti .
Henk Langeveld

8

Bu yüzden benim 5 anahtarım vardı ssh-agentve serser ssh anahtarını kullanma seçeneğine rağmen, doğru anahtarına ulaşmadan önce max_tries'e ulaşmadan önce ajanımdaki anahtarlar arasında dolaşmaya devam etti.

Bu sorunu ssh-add -lyaşadığınızı kontrol etmek için: Çalıştır - bu liste> 5 ise anahtarları kaldırmanız veya aracıyı devre dışı bırakmanız gerekir.

Düzeltmek için: Kaldırmak istediğiniz anahtarın ssh-add -d ~/.ssh/Xnerede Xolduğunu çalıştırın .


Mazer-rackham deposunu kurduktan sonra ve bu bilgiyi kullanarak probleminizi tekrar oluşturabilirim ve bir alternatif daha ekledim: serseri anahtarın aracı tarafından bilindiğinden emin olun.
Henk Langeveld

Aracıya ekledim ama yine de anahtarları kaldırmak zorunda kaldım. Belki de acenteye eklediğiniz emir önemlidir? EDIT: Sadece düzenlemenizi okuyun.
Ash

Aynı problemim var ama bunu nasıl çözdüğünüzü anlamıyorum? Anahtarlarımdan ~/.ssh/
hiçbirini klasörümden çıkaramıyorum

Anahtarları ~.sshklasörünüzden kaldırmıyorsunuz - anahtarları sizden kaldırıyorsunuz ssh-agent daemon. Bunları daha sonra tekrar ekleyebilirsiniz. Daha fazla bilgi için buraya bakınız .
Ash,

4

Tüm önerileri burada başarılı olmadan denedikten sonra, sorunumun her zaman başarısız olan yeni kimlik doğrulama yöntemi (GSSAPI) olduğunu kabul ettim.

Bunu ~/.ssh/configdosyayı düzenleyerek çözdüm:

Host *
  GSSAPIAuthentication no

Umarım bu da birine yardımcı olur.


Bu en azından bir slot oluşturuyor gibi görünüyor! 5 tuşlu ssh-agent üzerinden kurulumum tekrar çalışıyor. Sanırım 6 anahtarla başarısız olacak ...
Robert Siemer

2

Ssh aracınız, ssh sunucusunun kimlik doğrulama girişimlerine izin verdiğinden daha fazla anahtar içeriyor ("MaxAuthTries", varsayılan: 6).

Bazı ssh-ajanlarının, özellikle GNOME Anahtarının, ~ / .ssh içinde buldukları tüm anahtarları otomatik olarak yüklediğini ve bu anahtarların "ssh-add - [dD]" ile kaldırılamadığını unutmayın.

İşte bazı çözümler:

  • ~ / .Ssh / config'inizde doğru anahtarı önceden ayarladınız, bu nedenle aracıya ihtiyacınız yok. Müşterinin aracıyı görmezden gelmesini unset SSH_AUTH_SOCKsağlayın , örneğin @ henk-langeveld tarafından önerildiği gibi "IdentitiesOnly = yes" kullanın
  • Otomatik olarak yüklenmelerini önlemek için bazı tuşları ~ / .ssh (~ / .ssh / noauto benzeri bir alt dizin) dışına taşıyın. İhtiyacınız olursa hala manuel olarak ssh-ekleyebilirsiniz.
  • Sunucu tarafında "MaxAuthTries" değerini artırın, izin verilen kimlik doğrulama girişimi sayısı

2

Bunu önlemek için, ssh kullanarak -o 'IdentitiesOnly yes'örneğinssh -i privateKey -o 'IdentitiesOnly yes' user@host

alternatif olarak ~ / .ssh / config dosyasına şu satırları ekleyebiliriz

Host *
IdentitiesOnly yes

1

Hızlı düzeltme komutunu kullanarak sunucuyu bağlamak için:

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

Önerilen Yol aşağıda belirtilmiştir:

Ancak, ssh sunucunuzu bağlayan capistrano makbuzlarınız veya diğer yazılımlarınız varsa, aşağıda belirtildiği gibi doğru şekilde düzeltmeniz gerekir:

In ~ / .ssh / config sunucu yapılandırmasına dosya söz "IdentitiesOnly evet" seçeneği

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: Pem dosyası durumunda da ".pem" uzantısını belirtin


1

Esnek bir oyun kitabı çalıştırmaya çalışırken bu aynı hatayı yaşadım. IdentitiesOnly ssh seçeneğini aşağıdakileri kullanarak tedarik ettim --ssh-extra-args:

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

0

Anahtar mesaj

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

Vagrant ssh-config çıktısını varsayılan ana bilgisayar olarak kopyaladınız, .ssh/configancak çakışan parametreleri (ana bilgisayar adı, bağlantı noktası) olduğundan bu atlandı. Eşleşen bir giriş olmadan, ssh bulabileceği tüm anahtarları deneyecek.

-iSeçenekle ssh girişimini tekrar test edin

$ ssh -i $HOME/.vagrant.d/insecure_private_key vagrant@192.168.222.111 echo ok

Bunu Ansible Envanterinde nasıl belirleyeceğinize inanıyorum:

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

Okunabilirlik yolu kısaltıldı


Orijinal cevap:

vagrant ssh-configÇıktısını, içindeki serseri girişiyle karşılaştırın .ssh/config. Özel anahtar yolunun tam bir eşleşme olduğundan emin olun.

Ayrıca, anahtar dosyaya başka hesaplardan erişilemediğini de doğrulayın. Bu anahtarın ne olduğunu hepimiz biliyoruz, ancak SSH bu şeyin halka açık bir bilgi olduğunu bilmiyor ve bizi tehlikeye girebilecek anahtarların kullanılmasından korumaya çalışıyor.


İlk önce config dosyasını kopyaladım vagrant ssh-configama tekrar kontrol ettim ve aynı. Ayrıca cat /Users/ashleyconnor/.vagrant.d/insecure_private_keyyeterli izinlere de sahip olabilirim .
Ash

Başka kimsenin dosyayı okuyamadığından veya yazamadığından emin olun.
Henk Langeveld

1
Sadece rw izinlerim var. Diğer önerilere bir şans yok, ssh -i $HOME/.vagrant.d/insecure_private_key -l vagrant 192.168.222.111hala koşmaya çalıştımReceived disconnect from 192.168.123.123: 2: Too many authentication failures for vagrant
Ash

Uzak ana bilgisayarın bir kullanıcısı var vagrantmı?
Henk Langeveld

Evet. Çalıştırdığımda vagrant sshkullanıcı serseri olarak bağlanır
Ash
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.