Getrennt: Keine unterstützten Authentifizierungsmethoden verfügbar

12

Ich habe exakt das gleiche Problem in beschrieben diesem Thread , aber die Antwort akzeptierte es nicht die richtigen für mich ist, weil der Home - Verzeichnis 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 mir etwas auf der Serverseite fehlt (Linux, sshd), also poste ich den aktuellen /etc/ssh/sshd_configInhalt:

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, wie man sshd im Debug-Modus laufen lässt , 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 bad ownership or modes for directory /home/winwinbemerke ich die beiden 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 versucht, chmod 600wie in der Antwort unten 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/winwinFehler?

— WinWin
quelle

9

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

chmod g-w ~/

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

chmod 700 ~/.ssh

Machen Sie Ihre autorisierten Schlüsseldateien nur für Sie lesbar / beschreibbar :

chmod 600 ~/.ssh/authorized_keys

Das sollte die Berechtigungsfehler beseitigen.

— John T
quelle

Ich habe genau das getan, was Sie für ~/.sshund vorgeschlagen haben ~/.ssh/authorized_keys. Immer noch kein Glück. Was das Übernehmen der Gruppen-Schreibrechte aus dem Home-Verzeichnis selbst betrifft, kann ich das nicht tun, da dies den gesamten Zweck untergraben würde, für den dieser Benutzer / diese Gruppe erstellt wurde. Das Home-Verzeichnis dieses Benutzers muss von der Gruppe beschreibbar sein (mit exakt gleichem Namen und gid!). +1 für den Versuch zu helfen.

— WinWin

Vielen Dank! chmod g-w ~/rettete mich nach stundenlangem

— wahnsinn und haarziehen

Gah ya danke, ich habe mein Home-Verzeichnis mit meinem anderen Benutzer erstellt und es fehlte chmod gw ~ /

— Clarence Liu

5

Erfolg!

Alles, was ich tun musste, ist StrictModeszu Nein zu wechseln .

Siehe Abschnitt 3.14 in den OpenSSH-FAQ und http://blogs.nullvision.com/?p=114 .

Beeindruckend.

— WinWin
quelle

Hmm, das ist jedoch eher ein Workaround als eine Lösung. Lassen Sie mich etwas auf meiner Box überprüfen.

— Rob

Meine ls -lad .sshzeigt drwx, chmod 700 ~/.sshund die Dateien darin sind alle -rw, also - chmod 600 ~/.ssh/*SOLL- funktionieren.

— Rob

Macht nichts, sah Das Home - Verzeichnis des Benutzers durch die Gruppe beschreibbar sein muss (mit genau demselben Namen und gid!) Unten

— Rob

Dieser Weg ist nutzlos!

— Liebe

3

Hatte ein ähnliches Problem. Beim Stöbern bemerkte ich, dass ich meine privaten Verzeichnisse verschlüsselt hatte 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.

— rot
quelle

2

Es sieht so aus, als ob Ihre Berechtigungen für das Basisverzeichnis (oder möglicherweise Ihren Ordner .ssh / authorized_keys) falsch sind. Das Korrigieren dieser sollte das Anmeldeproblem beheben. Versuchen chmod 600 /home/winwin/.ssh/*
Sie, müssen Sie möglicherweise chmod 700 /home/winwin/.sshauch.

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

— Darth Android
quelle

Danke +1. Sehen Sie sich mein Update oben an, da ich immer noch nicht herausfinden kann, wie die richtigen Berechtigungen / Eigentümer lauten sollen.

— WinWin

Ich habe es gerade versucht chmod 600 /home/winwin/.ssh/*. Es hat nicht geholfen. : - /

— WinWin

1

@ WinWin hast du es auch im .sshVerzeichnis eingestellt? (Ich habe meine Antwort aktualisiert).

— Darth Android

Ja, habe ich. Immer noch kein Glück.

— WinWin

2

Ich kämpfte mich durch und fand schließlich eine Lösung, die keine potenzielle Sicherheitsverletzung hervorruft, wie dies bei StrictModes No der Fall ist.

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 von meiner Benutzerkonfiguration kopiert, die funktioniert hat, und presto! Die anderen Benutzernamen fingen auch an zu arbeiten!

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

— smcjones
quelle

1

Diese Fehlermeldung kann auch dadurch verursacht werden, dass SELinux den Zugriff auf sshd verhindert authorized_keys. Versuche dies:

restorecon -FRvv ~/.ssh

(aus dieser Antwort )

— RomanSt
quelle

0

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 {} \;

— Onkel Bob
quelle

3

Willkommen bei Super User! Es wäre schön, wenn Sie erklären könnten, was diese Befehle bewirken.

— Slhck

0

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 Ausgangsverzeichnisses 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).

— Philippe
quelle