it-swarm.com.de

Getrennt: Keine unterstützten Authentifizierungsmethoden verfügbar

Ich habe das gleiche genaue Problem, das in diesem Thread beschrieben ist , aber die dort akzeptierte Antwort ist nicht die richtige für mich, da das Basisverzeichnis des Benutzers ist lokal.

Ich denke, dass ich alles auf der Client-Seite richtig konfiguriert habe (Windows 7, PuTTY's PAGEANT, PUTTYGEN und PLINK), aber ich scheine nicht dafür zu sorgen, dass der Mechanismus für öffentliche Schlüssel funktioniert (passwortbasierte SSH-Anmeldung funktioniert). Ich folgte allen Schritten, Hinweisen und Hinweisen in:

Ich vermute jetzt, dass ich etwas auf der Serverseite vermisse (Linux, sshd), also poste ich den aktuellen /etc/ssh/sshd_config-Inhalt:

Protocol 2
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Irgendeine Idee, was ich falsch mache?

UPDATE: Ich habe einen Tipp gefunden, um sshd im Debug-Modus auszuführen, und hier ist die Ausgabe:

/home/winwin> /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.2p1
debug1: read PEM private key done: type RSA
debug1: private Host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private Host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.8 port 49828
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done

debug1: userauth-request for user winwin service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "winwin"
debug1: PAM: setting PAM_RHOST to "win7client"
debug1: PAM: setting PAM_TTY to "ssh"
Failed none for winwin from 192.168.1.8 port 49828 ssh2
debug1: userauth-request for user winwin service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
Failed publickey for winwin from 192.168.1.8 port 49828 ssh2
Received disconnect from 192.168.1.8: 14: No supported authentication methods available
debug1: do_cleanup
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanup

Jetzt bemerke ich die beiden bad ownership or modes for directory /home/winwin-Meldungen, aber ich habe den Besitz oder die Modi für das Verzeichnis/home/winwin und AFAICT überprüft. Sie sind in Ordnung:

/home> ls -lad winwin
drwxrwxr-x  21 winwin winwin 4096 Jul 13 21:24 winwin

Und:

/home/winwin> ls -lad .ssh
drwxr-xr-x  2 winwin winwin 4096 Jul 14 12:06 .ssh

Und:

/home/winwin/.ssh> ls -lad *
-rw-r--r--  1 winwin winwin 210 Jul 14 12:06 authorized_keys
-rw-r--r--  1 winwin winwin 210 Jul 14 01:58 authorized_keys.pub
-rw-r--r--  1 winwin winwin 394 Jul 14 01:57 authorized_keys.pub.orig

Was könnte möglicherweise falsch sein?

UPDATE II: Ich habe chmod 600 ausprobiert, wie in der folgenden Antwort vorgeschlagen:

/home/winwin> ls -lad .ssh
drw-------  2 winwin winwin 4096 Jul 14 13:13 .ssh

Und:

/home/winwin/.ssh> ls -lad *
-rw-------  1 winwin winwin 210 Jul 14 12:06 authorized_keys

Aber es geht immer noch nicht. Warum erhalte ich immer noch den Authentication refused: bad ownership or modes for directory /home/winwin-Fehler?

12
WinWin

Erfolg!

Ich musste nur StrictModes in no ändern.

Gemäß Abschnitt 3.14 in OpenSSH FAQ und http://blogs.nullvision.com /? p = 114 .

Beeindruckend.

5
WinWin

Versuchen Sie, die Gruppen-Schreibrechte aus Ihrem Home-Verzeichnis zu übernehmen:

chmod g-w ~/

Machen Sie Ihren .ssh-Ordner lesbar/beschreibbar/ausführbarnur für Sie:

chmod 700 ~/.ssh

Machen Sie Ihre autorisierte Schlüsseldatei lesbar/beschreibbarnur für Sie:

chmod 600 ~/.ssh/authorized_keys

Das sollte die Berechtigungsfehler beseitigen.

9
John T

Hatte ein ähnliches Problem. Beim Stöbern bemerkte ich, dass meine privaten Verzeichnisse verschlüsselt waren, und vermutete, dass dies das Problem war. Ich habe die Datei mit den autorisierten Schlüsseln in ein Verzeichnis außerhalb des verschlüsselten Basisverzeichnisses kopiert und die Berechtigungen entsprechend geändert (chmod 700 [dir], chmod 600 [dir]/authorized_keys usw.).

Bearbeiten Sie dann Ihre sshd_config, um sshd den neuen Speicherort für die Datei mit den autorisierten Schlüsseln mitzuteilen, starten Sie sshd neu und fertig.

Scheint mein Problem behoben zu haben.

3
red

Offenbar sind Ihre Berechtigungen für das Basisverzeichnis (oder möglicherweise für den Ordner .ssh/authorized_keys) falsch. Das Korrigieren dieser sollte das Anmeldeproblem beheben. chmod 600 /home/winwin/.ssh/* ausprobieren
Möglicherweise müssen Sie auch chmod 700 /home/winwin/.ssh.

SSHd weigert sich, Ihre authorized_keys-Datei zu laden, wenn sie nicht von Ihrem Benutzer (als Eigentümer) beschrieben werden kann, da dies ein Sicherheitsrisiko darstellt.

2
Darth Android

Ich kämpfte mich durch und fand schließlich eine Lösung, die keine potenzielle Sicherheitsverletzung verursacht, wie StrictModes Nein .

Stellen Sie sicher, dass Ihre Einstellungen wie folgt sind:

chmod 0755/home/ {userdir}

chmod 0700 /home/{userdir}/.ssh

chmod 0600 /home/{userdir}/.ssh/authorized_keys

Wobei {userdir} das betreffende Verzeichnis ist.

Der Schlüssel lautet chmod 0755, wodurch sichergestellt wird, dass nur der Benutzer auf das Home-Laufwerk schreiben kann. Ich habe dies aus meiner Benutzerkonfiguration kopiert, die funktioniert hat, und presto! Die anderen Benutzernamen haben ebenfalls funktioniert!

Hoffe das hilft anderen wie mir und spart dir ein paar Stunden Zeit.

2
smcjones

Diese Fehlermeldung kann auch durch SELinux verursacht werden, das verhindert, dass sshd auf authorized_keys zugreift. Versuche dies:

restorecon -FRvv ~/.ssh

(von dieser Antwort )

1
RomanSt

In meinem Fall war es das Ausgangsverzeichnis, das einen anderen Eigentümer (root) hatte als der tatsächliche Benutzer, zu dem dieses Ausgangsverzeichnis gehört (meine Dummheit beim Erstellen des Hauptverzeichnis mit root für einen anderen Benutzer).

Chown [user]:[group] /home/[user] 

hat dieses Problem behoben (und natürlich bleiben Sie bei den in anderen Antworten angegebenen Datei-/Verzeichnisberechtigungen).

0
Philippe
chown -R winwin.winwin /home/winwin/
chmod 700 /home/winwin/
find /home/winwin/ -type d -exec chmod 700 {} \;
find /home/winwin/ -type f -exec chmod 600 {} \;
0
Uncle Bob