SSH ohne Passwort (passwortlos) auf Synology DSM 5 als anderer (Nicht-Root-) Benutzer

24

Ich versuche, ohne Passwort (Authentifizierung mit öffentlichem Schlüssel), aber ohne Rootberechtigung, auf meine Synology Disk Station zu sshen.

Wenn ich versuche, als root ohne Passwort zu ssh, funktioniert es. Das Befolgen der exakt gleichen Schritte für einen anderen Benutzer funktioniert nicht. Es wird immer nach einem Passwort gefragt (auch die Verwendung eines Passworts funktioniert).

Ich habe alle Anleitungen dazu befolgt, aber ich denke, sie sind alle für DSM 4.x und nicht für die neue 5.0-Version.

SSH-Debug-Protokoll

Hier ist das Debug-Protokoll, wenn ich es mit dem Flag -vvv versuche:

aether@aether-desktop:~$ ssh -vvv aether@aether-ds.local
OpenSSH_6.2p2 Ubuntu-6ubuntu0.2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to aether-ds.local [192.168.2.149] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/aether/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/aether/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/aether/.ssh/id_rsa-cert type -1
debug1: identity file /home/aether/.ssh/id_dsa type -1
debug1: identity file /home/aether/.ssh/id_dsa-cert type -1
debug1: identity file /home/aether/.ssh/id_ecdsa type -1
debug1: identity file /home/aether/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v11
debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH_5*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "aether-ds.local" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA f1:57:47:37:47:d4:5c:cd:a7:a4:5a:9c:a3:e8:1d:13
debug3: load_hostkeys: loading entries for host "aether-ds.local" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "192.168.2.149" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'aether-ds.local' is known and matches the RSA host key.
debug1: Found key in /home/aether/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/aether/.ssh/id_rsa (0x7f4ee2f47200),
debug2: key: /home/aether/.ssh/id_dsa ((nil)),
debug2: key: /home/aether/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/aether/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/aether/.ssh/id_dsa
debug3: no such identity: /home/aether/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/aether/.ssh/id_ecdsa
debug3: no such identity: /home/aether/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
aether@aether-ds.local's password:

Jede Hilfe dankbar.

Dinge, die ich bisher versucht habe

Überprüfen Sie / etc / ssh / sshd_config (RSAAuthentication, PubkeyAuthentication, AuthorizedKeysFile).
Überprüfen Sie die .ssh / * -Perms und das Eigentumsrecht. Versuchte mehrere Kombinationen.
Überprüfen Sie HOME var in ~ / .profile.
Neustart von sshd über synoservicectl - Neustart von sshd und Neustart des gesamten NAS.

— Vlad A Ionescu
quelle

Warum willst du das machen? Würde die Authentifizierung mit einem öffentlichen Schlüssel mit einem ungeschützten Schlüssel nicht ausreichen?

— Daniel B

Hallo Daniel, genau das versuche ich zu erreichen, aber es funktioniert nicht für Nicht-Root-Benutzer.

— Vlad A Ionescu

Ist der öffentliche Schlüssel Ihres Kunden in der Benutzerdatei vorhanden authorized_keys ?

— Daniel B

Ja, ich habe es mit ssh-copy-id kopiert. Und es ist genau die gleiche authorized_keys-Datei (aber mit den richtigen Berechtigungen) vom root-Benutzer, die beim root funktioniert.

— Vlad A Ionescu

Hat Ihr Konto jetzt ein Passwort? Abhängig von den Sicherheitsrichtlinien Ihres Systems kann die Anmeldung von Benutzern ohne Kennwort gesperrt werden.

— Daniel B

49

Ich hatte das gleiche problem Ich starte eine Instanz von sshd im Debug-Modus auf der DiskStation mit "/ usr / syno / sbin / sshd -d", verbinde mich dann mit "ssh user @ DiskSation -vvv" und erhalte die Debug-Informationen auf dem Server:

......

debug1: temporary_use_uid: 1026/100 (e = 0/0)

debug1: versuchen Sie es mit der öffentlichen Schlüsseldatei /var/services/homes/user/.ssh/authorized_keys

debug1: fd 5 löscht O_NONBLOCK

Authentifizierung abgelehnt: Falscher Besitz oder Modi für Verzeichnis / Volume1 / Homes / Benutzer

......

Ich habe festgestellt, dass der Home-Ordner auch die richtigen Berechtigungen benötigt:

cd /var/services/homes/
chown <username> <username>
chmod 755 <username>

Und ersetzen Sie mit dem tatsächlichen Benutzernamen, wie "Benutzer".

Endlich ist das Problem gelöst!

— user334026
quelle

2

Genau wie für Sie löste das Ausführen chmod 755in meinem Home-Verzeichnis dies für mich auf DSM 6.

— David Pärsson

Es ist immer die richtige Lösung, um Debug-Protokolle abzurufen. Vielen Dank! Nur eine Ergänzung: Rufen Sie an /usr/bin/sshd -p 2222(und verbinden Sie sich mit ssh -p 2222), damit es für das Debugging auf einem anderen Port ausgeführt wird - andernfalls besteht die Gefahr, dass Sie den Zugriff verlieren, wenn Sie den SSH-Deamon beenden

— Alex

16

Sie müssen Ihr Home-Verzeichnis auf 755 ändern (Synology hat es standardmäßig auf 777).

nas> ls -al
total 28
drwxrwxrwx  6 root     root  4096 2014-07-13 03:00 .
drwxr-xr-x 13 root     root  4096 2014-07-13 03:00 ..
drwxrwxrwx  3 admin    users 4096 2014-07-13 03:00 admin
...
nas> chmod 755 /home/admin
nas> ls -al
total 28
drwxrwxrwx  6 root     root  4096 2014-07-13 03:00 .
drwxr-xr-x 13 root     root  4096 2014-07-13 03:00 ..
drwxr-xr-x  3 admin    users 4096 2014-07-13 03:00 admin

— falsche Daten
quelle

Dies zeigt nicht, dass chmod 755 /home/adminsich die Berechtigungen tatsächlich geändert haben.

— User20342

Ja, das ist wahr. Es ist mir jedoch gelungen, das geklebte Beispiel zusammenzufügen, und das habe ich verpasst. Ich werde die Antwort bearbeiten.

— spuriousdata

5

Da Ihre Berechtigungen für .sshund authorized_keys richtig eingestellt sind, stellen Sie einfach sicher, dass die Berechtigungen für Ihr Home-Verzeichnis ( /home/aether/) richtig eingestellt sind ( chmod 755 /home/aether/).

Ich konnte mich nicht mit den Standardberechtigungen ( 711) anmelden und es funktionierte nach dem Ändern der Berechtigungen.

Prost Stephan

— Stephan
quelle

2

Ich hatte das gleiche Problem, doppelte und dreifache Überprüfung aller oben genannten und immer noch nicht funktioniert. Schließlich stellte ich fest, dass der ssh-Daemon die Datei authorized_keys am falschen Ort suchte, da es kein Verzeichnis / home / nonrootuser gibt.

Sie sollten den Pfad erstellen oder einen Symlink erstellen (diese beiden Optionen haben bei mir nicht funktioniert) oder diese beiden Zeilen in die Datei sshd_config einfügen:

Match User nonrootuser
AuthorizedKeysFile      /var/services/homes/nonrootuser/.ssh/authorized_keys

Auf diese Weise stellen Sie sicher, dass der Schlüssel, den Sie über ssh-copy-id vom Client hinzufügen, derselbe ist, den der Server (Synology) anbietet, um die Verbindung für den Nicht-Root-Benutzer herzustellen.

— user334008
quelle

2

Dasselbe Problem hier mit dsm 6.0, das dank dieses Threads in den Synology-Foren behoben wurde

Es scheint, dass Benutzer zu viel Erlaubnis zu Hause sind????

chmod 755 /var/services/homes/[username]

... und jetzt klappt es!

— Gonzalo Cao
quelle

1

Es sieht dieser Frage sehr ähnlich:

/programming/12839106/scp-between-2-remote-hosts-without-password/12945060#12945060

Ich vermute, dass Ihr .ssh-Verzeichnis oder Ihre Dateien nicht die richtigen Attribute haben.

Hier sind meine:

-rw-r--r--  1 root root   393 Aug 13  2012 if_rsa.pub
-rw-------  1 root root  1675 Aug 13  2012 if_rsa
-rw-r--r--  1 root root   393 Aug 20  2012 id_rsa.pub
-rw-------  1 root root  1675 Aug 20  2012 id_rsa
-rw-------  1 root root  4606 Aug  7  2013 authorized_keys
drwx------  2 root root  4096 Feb 24 09:59 .
-rw-r--r--  1 root root 11354 Mar 25 17:28 known_hosts

Überprüfen Sie auch den Inhalt, der /etc/pam.d/sshdmöglicherweise Einschränkungen für Nicht-Root-Benutzer enthält. Nur für den Fall. Dieser Link erklärt PAM im Fall von RHEL. Dies kann helfen: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/PAM_Configuration_Files.html

Hier zeigt das Problem seinen hässlichen Kopf:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/aether/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password

Es akzeptiert id_rsa nicht und fährt fort:

debug1: Trying private key: /home/aether/.ssh/id_dsa
debug1: Trying private key: /home/aether/.ssh/id_ecdsa

Es gibt auf und verlässt sich auf Passwort

debug1: Next authentication method: password

Die Frage ist nun, warum es nicht gefällt, id_rsa?

— Grzegorz
quelle

Hallo Grzegorz, die .ssh dir hat Dauerwelle 700 und .ssh / authorized_keys hat Dauerwelle 600.

— Vlad A Ionescu

@VladAlexandruIonescu: Ich habe meine Antwort mit anderen Attributen und Informationen zu PAM aktualisiert, die Ihnen möglicherweise mehr zu testenden Bereich bieten.

— Grzegorz

Danke, Grzegorz, aber immer noch kein Glück. Ich habe genau die gleichen Dauerwellen wie deine ausprobiert. Schauen Sie sich auch in /etc/pam.d/sshd um, aber nichts würde den Root-Benutzer diskriminieren: gist.github.com/vlad-alexandru-ionescu/e6a2ee6133c7e9e45273 .

— Vlad A Ionescu

@VladAlexandruIonescu: Ist das Problem für alle Benutzer? Sie haben "für einen anderen Benutzer" geschrieben, der möglicherweise nur einen Benutzer angibt. Können Sie mit diesem Benutzer-Login putty oder Sie sind als root angemeldet und dann su es?

— Grzegorz

Ja, für alle Benutzer ohne Rootberechtigung. Ich kann als jeder Benutzer (root oder nicht root) ssh / putty. Wenn Sie nicht als Root angemeldet sind, werden Sie nach einem Kennwort gefragt, obwohl ich den öffentlichen Schlüssel meines Clients zu authorized_keys auf dem Server hinzugefügt habe.

— Vlad A Ionescu

1

Ich hatte das gleiche Problem. Nach dem Einrichten der korrekten Berechtigungen für die Verzeichnisse "authorized_keys", "file home" und ".ssh" konnte ich immer noch keine SSH-Verbindung zu meiner Diskstation herstellen.

Nachdem ich die Informationen auf techanic.net gelesen hatte, stellte ich fest, dass ich auch meine Anmeldeshell in meiner /etc/passwdDatei festlegen musste . Es wurde /sbin/nologinstandardmäßig eingestellt. Nachdem /bin/shich es auf geändert hatte, konnte ich erfolgreich SSH auf meine Diskstation übertragen.

— Rob Szumlakowski
quelle

0

Ich hatte gerade das gleiche Problem mit DSM 5.1 anstelle von 5.0. Keine der aufgeführten Lösungen hat das Problem gelöst. In meinem Fall waren die Berechtigungen für /var/services/homes/<user>/.ssh/authorized_keysnicht korrekt. Das Ausführen des Folgenden löste das Problem

chmod 600 /var/servieces/homes/<user>/.ssh/authorized_keys

— Steven C. Howell
quelle