SSH: Odmowa zezwolenia (publickey, gssapi-with-mic, hasło)

================================================== ==================

AKTUALIZACJA: Okazało się, że konfiguracja sshd host2nie pozwoli na logowanie się za pomocą hasła. Dzięki ludziom odpowiedzieli na to pytanie.

================================================== ==================

Scenariusz: praca z firmą dla mojego projektu college'u. Muszę użyć PuTTy do SSH do host1pierwszego, a stamtąd SSH do host2(patrz poniżej). Otrzymałem nazwę użytkownika i hasło na hoście 2.

W ogóle nie mam dostępu do host2, więc nie mam o nim wiedzy sshd_config.

To, co się stało, kiedy starałem się do SSH host2z host1:

ff@host1:~$ ssh -v host2
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/ff/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host2 [192.*.*.*] port 22.
debug1: Connection established.
debug1: identity file /home/ff/.ssh/identity type -1
debug1: identity file /home/ff/.ssh/id_rsa type -1
debug1: identity file /home/ff/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sd01' is known and matches the RSA host key.
debug1: Found key in /home/ff/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Trying private key: /home/ff/.ssh/identity
debug1: Trying private key: /home/ff/.ssh/id_rsa
debug1: Trying private key: /home/ff/.ssh/id_dsa
debug1: Next authentication method: password
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).

i mój /home/ff/.ssh/config:

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   HostbasedAuthentication no
    BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   AuthorizedKeysFile .ssh/authorized_keys
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

Zastanawiam się, czy mogę coś zrobić przed pójściem do firmy.

Nazwa użytkownika i hasło, których próbujesz, nie są akceptowane przez hosta. Oznacza to, że łączysz się z niewłaściwym serwerem lub nazwa użytkownika lub hasło są niepoprawne. Powinieneś poprosić administratora o sprawdzenie logów host2, co powinno powiedzieć, który z tych trzech przypadków ma miejsce.

Pierwszy

 chmod 700 .ssh

i wtedy :

 chmod 600 .ssh/authorized_keys

i przetestuj to:

restorecon -r -vv .ssh/authorized_keys

W moim przypadku było to spowodowane szyfrowaniem katalogu domowego. Zmieniłem położenie kluczy ssh i rozwiązało to problem: (kopia archiwum internetowego) http://tweaktheserver.com/ssh-cant-connect-authentications-that-can-continue-publickeygssapi-keyexgssapi-with-micpassword/

Uwierzytelnianie GSSAPI wydaje się być włączone w kliencie, ale zawiesza się i wraca do uwierzytelniania hasłem. Jeśli nie możesz zalogować się przy użyciu podanego loginu i hasła, jedyną rozsądną rzeczą jest skontaktowanie się z osobą odpowiedzialną za zarządzanie serwerem („firma”).

Miałem ten sam problem, ale dla mnie problemem było to, że domyślna konfiguracja systemu operacyjnego (CentOS 7) polegała na szyfrowaniu katalogu użytkownika, tak aby authorized_keysumieszczony w nim plik ~/.ssh/nie działał. Rozwiązanie pochodzi stąd, ale w zasadzie:

1. w /etc/ssh/sshd_configzestawie właściwość AuthorizedKeysFile na coś poza katalogiem użytkownika ( /etc/ssh/authorized_keys)
2. uruchom ponownie usługę sshd

try:
serwer ssh -p port -o PreferredAuthentications = publickey

Musiałem dać /home/ec2-useruprawnienia 700:

chmod -R 700 /home/ec2-user/

Dodam, że powinieneś upewnić się, że klucz należy do użytkownika.

Wpisz, ls -laaby zobaczyć, do którego użytkownika należy Twój klucz.

Możesz zmienić własność:

sudo chown ubuntu:root myKey  //If you are using ubuntu.

Upewnij się również:

• Używasz poprawnego .pemklucza, jeśli używasz linuxa (kit jest inny)
• Ustawiłeś prawidłowe uprawnienia klucza: sudo chmod 400 mykey.pem
• Używasz poprawnej nazwy użytkownika: ssh -i mykey user@instanceip

Możesz spróbować

ssh server -l user -o "PubkeyAuthentication=no"

LUB w / etc / ssh / sshd_config, dodaj / zmodyfikuj właściwość

PermitRootLogin yes

$ ssh [email protected] -i .vagrant / Machines / default / virtualbox / private_key

To zadziałało dla mnie