Próbuję uruchomić ten prosty skrypt obsługi administracyjnej, ale występują błędy podczas uruchamiania, vagrant up
a następnie vagrant provision
poleceń.
Przeczytałem, że muszę utworzyć /etc/ansible/hosts
plik, który zrobiłem, wypełniając go:
[vagrant]
192.168.222.111
Moja konfiguracja SSH (niektóre szczegóły zostały usunięte):
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
Wydaje mi się, że wyjście SSH przechodzi przez wszystkie moje klucze:
<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
vagrant ssh
Komenda działa dobrze.
vagrant ssh
a to pytanie dotyczyło tylko uwierzytelnienia bezkluczykowego.IdentitiesOnly=yes
Odpowiedzi:
Zgodnie z
ssh-config(5)
, ssh zawsze wypróbuje wszystkie klucze znane przez agenta oprócz wszystkich plików tożsamości:Aby temu zapobiec,
IdentitiesOnly=yes
oprócz jawnie podanego klucza prywatnego należy określić .Na przykład uruchomienie
ssh
poniższej komendy:produkuje:
Jednak uruchomienie tej samej
ssh
komendy i dodatkowo określenieIdentitiesOnly=yes
:produkuje:
źródło
.ssh/config
pliku składnia znajduje sięIdentitiesOnly yes
w odpowiednichHost
sekcjach.ssh -o Option=Value
staje sięOption Value
w pliku konfiguracyjnym.ssh
opcji klienta.Miałem więc 5 kluczy
ssh-agent
i pomimo wyraźnej opcji użycia błędnego klucza ssh, nadal nalegałem na przechodzenie między kluczami w moim agencie, zanim wygodnie dotrzesz do max_tries, zanim dojdziesz do właściwego klucza.Aby sprawdzić, czy masz ten problem: Uruchom
ssh-add -l
- jeśli ta lista ma> 5, musisz usunąć klucze lub wyłączyć agenta.Aby naprawić: Uruchom
ssh-add -d ~/.ssh/X
gdzieX
jest klucz, który chcesz usunąć.źródło
~/.ssh/
folderu, potrzebuję wtedy~.ssh
folderu - usuwasz klucze zssh-agent daemon
. Zawsze możesz dodać je później. Zobacz tutaj, aby uzyskać więcej informacji.Po wypróbowaniu wszystkich porad tutaj bez powodzenia, zrozumiałem, że moim problemem była nowa metoda uwierzytelniania (GSSAPI), która zawsze była nieudana.
Rozwiązałem to, edytując
~/.ssh/config
plik:Mam nadzieję, że to też komuś pomoże.
źródło
Twój agent ssh posiada więcej kluczy niż serwer ssh pozwala na próby uwierzytelnienia („MaxAuthTries”, domyślnie: 6).
Zauważ, że niektórzy agenci ssh, w szczególności GNOME Keyring, automatycznie ładują wszystkie klucze znalezione w ~ / .ssh i że tych kluczy nie można wyładować za pomocą „ssh-add - [dD]”.
Oto kilka rozwiązań:
unset SSH_AUTH_SOCK
Lub użyj „IdentitiesOnly = yes”, jak sugerował @ henk-langeveldźródło
Aby temu zapobiec, możemy ssh używając
-o 'IdentitiesOnly yes'
npssh -i privateKey -o 'IdentitiesOnly yes' user@host
alternatywnie możemy dodać następujące wiersze do pliku ~ / .ssh / config
źródło
Aby połączyć się z serwerem za pomocą polecenia szybkiej poprawki:
Zalecany sposób wymieniono poniżej:
Ale jeśli masz recepty capistrano lub inne oprogramowanie, które łączą twój serwer ssh, musisz to naprawić w odpowiedni sposób, jak wspomniano poniżej:
W pliku ~ / .ssh / config wspomnij o opcji „IdentitiesOnly yes” w konfiguracji serwera
private_key_OR_pem_file: W przypadku rozszerzenia pliku pem też wspomnij o rozszerzeniu „.pem”
źródło
Wystąpił ten sam błąd podczas próby uruchomienia podręcznika ansible. W końcu dostarczyłem opcję ssh IdentitiesOnly, używając
--ssh-extra-args
:źródło
Kluczowym przesłaniem jest
Skopiowałeś błędne wyjście ssh-config jako domyślnego hosta,
.ssh/config
ale jest ono pomijane, ponieważ ma sprzeczne parametry (nazwa hosta, port). Bez pasującego wpisu ssh wypróbuje wszystkie klucze, jakie może znaleźć.Przetestuj ponownie próbę ssh z
-i
opcjąSądzę, że tak określiłbyś to w Inwentarzu Ansible:
Skrócono ścieżkę dla czytelności
Oryginalna odpowiedź:
Porównaj wyniki
vagrant ssh-config
z błędnym wpisem w twoim.ssh/config
. Upewnij się, że ścieżka klucza prywatnego jest dokładnie zgodna.Sprawdź także, czy do pliku klucza nie mogą uzyskać dostępu żadne inne konta. Wszyscy wiemy, co to jest klucz, ale SSH nie wie, że to jest wiedza publiczna i próbuje nas chronić przed użyciem kluczy, które mogą zostać naruszone.
źródło
vagrant ssh-config
ale sprawdziłem ponownie i jest identyczna. Mogę równieżcat /Users/ashleyconnor/.vagrant.d/insecure_private_key
i mam odpowiednie uprawnienia.ssh -i $HOME/.vagrant.d/insecure_private_key -l vagrant 192.168.222.111
nadal biegaćReceived disconnect from 192.168.123.123: 2: Too many authentication failures for vagrant
vagrant
?vagrant ssh
łączy się jako włóczęga użytkownika