SSH припиняє роботу із занадто багатьма помилками аутентифікації


26

Я намагаюся запустити цей простий сценарій забезпечення, але у мене виникають помилки під час запуску, vagrant upа потім vagrant provisionкоманд.

Я прочитав, що мені потрібно створити /etc/ansible/hostsфайл, який я зробив, заповнивши його:

[vagrant]
192.168.222.111

Мій конфігурація SSH (деякі дані видалено):

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

Вихід SSH, який я отримую, здається, працює через усі мої клавіші:

<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 sshКоманда працює відмінно.


Можливий дублікат: serverfault.com/questions/139870/…
Henk Langeveld

Трохи інший. Vagrant вводить це ключ під час запуску, vagrant sshі це питання стосувалося лише безключової аутентифікації.
Еш

2
Додавання примітки для інших людей Погуглили це. Ця ж проблема страждає від комутаторів Cisco Nexus. Вирішується так, як вказувало @HenkLangeveld нижче:IdentitiesOnly=yes
Brett Lykins

Відповіді:


37

Відповідно ssh-config(5), ssh завжди намагатиметься виконати всі ключі, відомі агентом, крім будь-яких файлів посвідчень:

 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.

Щоб цього не допустити, потрібно вказати IdentitiesOnly=yesна додаток до чітко наданого приватного ключа.

Наприклад, запустивши sshкоманду нижче:

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

виробляє:

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

Однак, запускаємо ту саму sshкоманду і, крім того, вказуючи IdentitiesOnly=yes:

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

виробляє:

ok

Редагувати: Видалено неправильне припущення про необхідність додати ключ бродячого до агента. Це зменшує відповідь до її суті. Подивимось, чи зможемо ми знайти дублікат ...
Хенк Лангевельд

3
Дякую за пояснення! При використанні .ssh/configфайлу синтаксис знаходиться IdentitiesOnly yesу відповідних Hostрозділах.
чорт

Правильно, ssh -o Option=Valueстає Option Valueу конфігураційному файлі.
Хенк Лангевельд

вибачте, якщо питання занадто основне, але чи "IdentitiesOnly = так" на стороні сервера чи аргумент, який потрібно передати клієнту? Схоже, другий ..
RollRoll

@ThePoet Дійсно, згадував це як sshваріант клієнта.
Henk Langeveld

8

Тож у мене було 5 ключів, ssh-agentі, незважаючи на явний варіант використання клавіші ssh, він все ще наполягав на перегляді ключів у мого агента, перш ніж зручно досягти max_tries, перш ніж перейти до потрібної клавіші.

Щоб перевірити, чи є у вас проблема: Запустіть ssh-add -l- якщо в цьому списку> 5, вам потрібно видалити ключі або відключити агент.

Для виправлення: запустіть, ssh-add -d ~/.ssh/Xде Xє ключ, який потрібно видалити.


Після установки репорта mazer-rackham і з цією інформацією я міг би відтворити вашу проблему, і я додав альтернативу: Переконайтесь, що блукаючий ключ відомий агентом.
Хенк Лангевельд

Я додав його до агента, але все-таки довелося видалити ключі. Можливо, порядок, який ви додаєте до агента, має значення? РЕДАКТИРУЙТЕ: Просто прочитайте вашу редакцію.
Еш

У мене така ж проблема, але я не розумію, як ви це вирішили? Я не можу видалити жоден із ключів зі своєї ~/.ssh/папки, мені потрібно
rubo77,

Ви не видаляєте ключі зі своєї ~.sshпапки - ви виймаєте ключі з ssh-agent daemon. Ви завжди можете їх додати пізніше. Дивіться тут для отримання додаткової інформації.
Еш

4

Після того, як я без успіху спробував тут усі поради, я визнав, що моєю проблемою був новий метод аутентифікації (GSSAPI), який завжди був невдалим.

Я вирішив це шляхом редагування ~/.ssh/configфайлу:

Host *
  GSSAPIAuthentication no

Сподіваюся, це теж допомагає комусь.


Здається, щонайменше складається один слот! Моя настройка з 5 клавішами через ssh-агент знову працює. Я думаю, що це не вдасться за допомогою 6 клавіш ...
Роберт Сімер

2

Ваш ssh-агент містить більше ключів, ніж ssh-сервер дозволяє спроби аутентифікації ("MaxAuthTries", за замовчуванням: 6).

Зауважте, що деякі ssh-агенти, зокрема GNOME Keyring, автоматично завантажують усі ключі, які вони знаходять у ~ / .ssh, і що ці ключі не можна вивантажувати з "ssh-add - [dD]".

Ось кілька рішень:

  • Ви вже налаштували правильний ключ у своєму ~ / .ssh / config, тому агент вам не потрібен. unset SSH_AUTH_SOCKЗмусьте клієнта ігнорувати агент, наприклад, або використовувати "IdentitiesOnly = так", як запропонував @ henk-langeveld
  • Перемістіть кілька клавіш із ~ / .ssh (також працює такий піддіар, як ~ / .ssh / noauto), щоб запобігти автоматичному завантаженню. Ви можете ще ssh-додати їх вручну, якщо вони вам потрібні.
  • Збільшити "MaxAuthTries" на стороні сервера, кількість дозволених спроб аутентифікації

2

Щоб запобігти цьому, ми можемо ssh, використовуючи -o 'IdentitiesOnly yes'напрssh -i privateKey -o 'IdentitiesOnly yes' user@host

Крім того, ми можемо додати наступні рядки до файлу ~ / .ssh / config

Host *
IdentitiesOnly yes

1

Для підключення сервера за допомогою команди швидкого виправлення:

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

Рекомендований спосіб згадується нижче:

Але якщо у вас є приймачі capistrano або інші програмні засоби, які з'єднують ваш ssh-сервер, вам доведеться виправити належним чином, як зазначено нижче:

У файлі ~ / .ssh / config в конфігурації сервера згадується параметр "IdentitiesOnly yes"

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 також згадується розширення ".pem"


1

Я зіткнувся з цією самою помилкою, намагаючись запустити ангібельну книжку. Я в кінцевому підсумку поставив опцію IdentitiesOnly ssh за допомогою --ssh-extra-args:

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

0

Ключове повідомлення є

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

Ви скопіювали вигідний вихід ssh-config як хост за замовчуванням, .ssh/configале це пропускається, оскільки він має суперечливі параметри (ім'я хоста, порт). Без відповідного запису, ssh просто спробує всі клавіші, які він може знайти.

Перевірте сш спробу за допомогою -iпараметра

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

Я вважаю, що саме так ви б вказали це в Інвентарному списку відповідей:

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

Скорочений шлях для читабельності


Оригінальна відповідь:

Порівняйте висновок vagrant ssh-configз бродячим записом у вашому .ssh/config. Переконайтеся, що шлях приватного ключа точно збігається.

Також переконайтесь, що до файлу ключів не можна отримати доступ до будь-яких інших облікових записів. Ми всі знаємо, що це за ключ, але SSH не знає, що ця річ є загальнодоступною, і намагається захистити нас від використання ключів, які можуть бути порушені.


Я спочатку скопіював конфігурацію, vagrant ssh-configале я перевірив ще раз, і вона однакова. Я також можу cat /Users/ashleyconnor/.vagrant.d/insecure_private_keyі мати відповідні дозволи.
Еш

Переконайтесь, що ніхто більше не може прочитати або записати файл.
Хенк Лангевельд

1
Тільки у мене є rw дозволи. В інших пропозиціях не пощастило, я спробував ssh -i $HOME/.vagrant.d/insecure_private_key -l vagrant 192.168.222.111все-таки дістатисьReceived disconnect from 192.168.123.123: 2: Too many authentication failures for vagrant
Ash

Чи має віддалений хост користувача vagrant?
Хенк Лангевельд

Так. Коли я запускаю, vagrant sshвін підключається як користувач бродячий
Ash
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.