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

16

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

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.

Gurke
quelle
Ist der Benutzername "ff" auf Host 2 korrekt?
Etagenklo
@etagenklo ja das ist was mir gegeben wurde.
Gurke
Sie sollten den Administrator von fragen host2.
23.
Ich hatte das gleiche Problem. Ich glaube, die Ursache ist, dass im Ordner $ HOME / .ssh des Benutzers ein Fehler aufgetreten ist. Nach mv $ HOME / .ssh $ HOME / .ssh.hide konnte ich mich mit dem
SSH-

Antworten:

8

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.

Kasperd
quelle
2
Es ist, als könntest du noch dümmer sein, wenn ich die richtigen Passwörter habe. Und dann erinnern Sie sich an verschiedene Tastaturlayouts. Vielen Dank, dass Sie mich zu einem
erneuten Besuch veranlasst haben
@ skyw00lker Das ist der Grund, warum ich persönlich alphanumerische Passwörter verwende.
Kasperd
6

Zuerst

 chmod 700 .ssh

und dann :

 chmod 600 .ssh/authorized_keys

und teste dies:

restorecon -r -vv .ssh/authorized_keys
Ali Zemani
quelle
1
Das funktioniert. Vielen Dank!
NightKnight auf Cloudinsidr.com
2

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/

user173141
quelle
2
Bitte geben Sie das Wesentliche der Lösung in Ihre Antwort ein. Nur-Link-Antworten sind anfällig für Link-Rot.
Deer Hunter
Während dies theoretisch die Frage beantworten mag, wäre es vorzuziehen , die wesentlichen Teile der Antwort hier aufzunehmen und den Link als Referenz bereitzustellen.
Mark Henderson
danke für eure vorschläge. Ich verstehe, dass ein funktionierender Link in Zukunft ein Fehler sein kann, und es ist wichtig, die Punkte in der Antwort selbst zu erwähnen. Ich habe meine Antwort ebenfalls bearbeitet.
user173141
@ DeerHunter war prophetisch: Link verfault
Riet
@Riet - bearbeiten vorgeschlagen. Alles ist nicht verloren. In der Zwischenzeit können Sie die erfasste Kopie der Seite besuchen .
Deer Hunter
1

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.

phoops
quelle
1

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
Anatoly Geyfman
quelle
0

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

Alexandr Vladimirovich
quelle
Seien Sie bitte etwas ausführlicher darüber, warum das OP Ihren Befehl verwenden soll und was es tut. Auch code stylingfür Befehle gilt als guter Stil:``
Phillip-Zyan K Lee- Stockmann
-1

Ich musste /home/ec2-userBerechtigungen 700 geben:

chmod -R 700 /home/ec2-user/
duhaime
quelle
Warum die Stimme löschen?
Duhaime
-1

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
JPaulino
quelle
-2

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
Adriano
quelle
ssh server -l user -o "PubkeyAuthentication=no" gleich ssh user@server -o "PubkeyAuthentication=no"
Adriano
-2

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

Das hat bei mir funktioniert

karthik br
quelle