SSH: Erlaubnis verweigert (publickey, gssapi-with-mic, Passwort)

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

UPDATE: Es stellte sich heraus, dass die Konfiguration von sshd keine host2Passwortanmeldung zulässt. Vielen Dank an die Leute, die darauf geantwortet haben.

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

Szenario: Mit einer Firma für mein College-Projekt arbeiten. Ich muss PuTTy zuerst für SSH host1und dann für SSH verwenden host2(siehe unten). Ich habe auf host2 einen Benutzernamen und ein Passwort erhalten.

Ich habe überhaupt keinen Zugriff auf host2, daher habe ich keine Kenntnis davon sshd_config.

Dies ist, was passiert ist, als ich versucht habe, in SSH host2von 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).

und mein /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

Ich frage mich, ob ich irgendetwas tun kann, bevor ich in die Firma gehe.

Der Benutzername und das Passwort, die Sie versuchen, werden vom Host nicht akzeptiert. Das bedeutet, dass Sie entweder eine Verbindung zum falschen Server herstellen oder der Benutzername oder das Passwort falsch sind. Sie sollten den Administrator bitten, die Anmeldungen zu überprüfen host2, damit Sie wissen, welcher der drei Fälle der Fall ist.

Zuerst

 chmod 700 .ssh

und dann :

 chmod 600 .ssh/authorized_keys

und teste dies:

restorecon -r -vv .ssh/authorized_keys

In meinem Fall wurde es durch die Verschlüsselung des Home-Verzeichnisses verursacht. Ich habe die Lage des SSH - Schlüssels geändert und das Problem gelöst: (Webarchiv Kopie) http://tweaktheserver.com/ssh-cant-connect-authentications-that-can-continue-publickeygssapi-keyexgssapi-with-micpassword/

Die GSSAPI-Authentifizierung scheint auf dem Client aktiviert zu sein, schlägt jedoch fehl und greift auf die Kennwortauthentifizierung zurück. Wenn Sie sich nicht mit dem angegebenen Login und Passwort anmelden können, ist es nur sinnvoll, sich an eine für die Serververwaltung zuständige Person (die "Firma") zu wenden.

Ich hatte das gleiche Problem, aber das Problem für mich war, dass die Standardkonfiguration des Betriebssystems (CentOS 7) darin bestand, das Benutzerverzeichnis zu verschlüsseln, sodass die darin authorized_keysabgelegte Datei ~/.ssh/nicht funktionieren würde. Die Lösung kam von hier aber grundsätzlich:

1. in /etc/ssh/sshd_configsetze die AuthorizedKeysFile Eigenschaft auf etwas außerhalb des Benutzerverzeichnisses ( /etc/ssh/authorized_keys)
2. Starten Sie den sshd-Dienst neu

Versuch:
ssh Server -p Port -o PreferredAuthentications = publickey

Ich musste /home/ec2-userBerechtigungen 700 geben:

chmod -R 700 /home/ec2-user/

Lassen Sie mich hinzufügen, dass Sie sicherstellen sollten, dass der Schlüssel Ihrem Benutzer gehört.

Geben Sie ein, um ls -lazu sehen, welchem ​​Benutzer Ihr Schlüssel gehört.

Sie können den Eigentümer ändern:

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

Stellen Sie außerdem sicher:

• Sie verwenden den richtigen .pemSchlüssel, wenn Sie Linux verwenden (Putty ist anders)
• Sie haben die richtigen Schlüsselberechtigungen festgelegt: sudo chmod 400 mykey.pem
• Sie verwenden den richtigen Benutzernamen: ssh -i mykey user@instanceip

Du kannst es versuchen

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

ODER fügen Sie in / etc / ssh / sshd_config die Eigenschaft hinzu / ändern Sie sie

PermitRootLogin yes

$ ssh Vagrant@192.168.33.11 -i .vagrant / machines / default / virtualbox / private_key

Das hat bei mir funktioniert