SSH Login für Non-root User mit Key?

[Nomad]

Beim Einloggen in DS216j mit SSH als User werde ich nach Passwort gefragt obwohl der Schlüssel in $HOME/.ssh/authorized_keys installiert ist.

Für root klappt das ohne Passwortabfrage. Was muss ich tun um die Passwortabfrage auch für andere User abzuschalten?

Danke.

 

[Tommi2day]

Ich gehen davon aus, das wirklich der Public-Key des User in der authorized_keys. gelandet ist. Bei von Putty generierten Keys muss man die erst in das OpenSSH Format exportieren.
Die authorized_keys muss die Rechte "0600" für den User habe, das übergeordnete Verzeichnis keine Schreibrechte für die Gruppe und others, e.g "0755"

 

[Nomad]

Es lag an den Zugriffsrechten des Heimatverzeichnisses. DSM legt sie mit der Permission 777 an. Nach "chmod go-w $HOME" war das Problem behoben. Der Tipp war also schon richtig aber eine Verzeichnisstufe drüber.

 

[speerwerfer]

Ich hänge mich mal hier dran, da ich nicht weiter komme.

Ich habe auf meinem Linuxlaptop mir die Keys als User mb generiert (ssh-keygen -t rsa) und den public Key auf der DS215j mit DSM 5.2-5644 Update 5 in die Datei ~/.ssh/authorized_keys des Users backup kopiert.

Dann habe ich noch dies hier auf der DS215j gemacht:

$ chmod 0700 ~/.ssh
$ chown -R EUER_BENUTZER ~/.ssh
$ chmod 0600 ~/.ssh/authorized_keys

$ synoservicectl --reload sshd

Wenn ich mich nun per SSH einlogen möchte (ssh backup@ds215j) kommt trotzdem die Aufforderung das Passwort von dem user backup einzugeben.

Das hier spukt die Option -v mit aus:

mb@lola ~ $ ssh -v backup@192.168.0.101
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.101 [192.168.0.101] port 22.
debug1: Connection established.
debug1: identity file /home/mb/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mb/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mb/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mb/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mb/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mb/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mb/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mb/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6p2-hpn14v4
debug1: match: OpenSSH_6.6p2-hpn14v4 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000000
debug1: Authenticating to 192.168.0.101:22 as 'backup'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: anonymanonym
debug1: Host '192.168.0.101' is known and matches the ECDSA host key.
debug1: Found key in /home/mb/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mb/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/mb/.ssh/id_dsa
debug1: Trying private key: /home/mb/.ssh/id_ecdsa
debug1: Trying private key: /home/mb/.ssh/id_ed25519
debug1: Next authentication method: password
backup@192.168.0.101's password:

Was mache ich falsch?

Martin

 

[Nomad]

Auf dem ersten Blick würde ich sagen id_rsa und id_rsa.pub passen nicht zusammen.

Wenn die passende id_rsa.pub als authorized_key hinterlegt ist sollte nach

Offering RSA public key: ..../id_rsa

die Zeilen

Server accepts key: ...
Authentication succeedet (publickey).

zu sehen sein.

So klappert er auf der Suche nach passenden Key alle Möglichkeiten ab bis er zum Schluss nach Passwort fragt.

Probiere doch mal lokal oder anderen Rechner ob das geht, um festzustellen ob es ein generelles oder Synology Problem ist.

 

[Fusion]

Es ist unklar unter welchem user du welche Befehle auf der Konsole benutzt. Wenn du ~ benutzt bezieht sich das auf das Home-Verzeichnis des angemeldeten Benutzers.
Von daher vermute ich, dass du hier einfach in den falschen Verzeichnissen operiert hast und deshalb die richtigen Daten nicht gefunden werden können.

Edit:
Da wäre es übersichtlicher, wenn du mit absoluten Pfaden arbeitest

 

[speerwerfer]

Ich habe den Pub Key meines Laptops mal auf meinen Server bei Uberspace kopiert. Da klappt das problemlos.

Nun habe ich auf der DS noch mal einen neuen User (backupuser) angelegt und versucht das mit dem einzurichten. Klappte nicht.

Dann hab ich mir die Verzeichnisrechte noch einmal angesehen. Und ich bin hierüber gestolpert:

Wenn ich als root auf der DS bin, sehe ich dies:

DS215> ls -al /volume1/homes/                
drwx--x--x    9 root     root          4096 Feb  4 15:54 .
drwxr-xr-x   19 root     root          4096 Feb  4 15:44 ..
drwxrwxrwx    3 root     root          4096 Jan  3 20:15 @eaDir
drwx--x--x    4 admin    users         4096 Feb  4 09:55 admin
drwx--x--x    3 backupus users         4096 Feb  4 15:55 backupuser
drwx--x--x    2 guest    users         4096 Jun 29  2015 guest

Bin ich als backupuser auf der DS, sehe ich das:

DS215> ls -al /volume1/homes/backupuser
drwxrwxrwx    3 backupus users         4096 Feb  4 15:55 .
drwx--x--x    9 root     root          4096 Feb  4 15:54 ..
drwxr-xr-x    2 backupus users         4096 Feb  4 15:57 .ssh

Das $HOME von backupuser hat zwei unterschiedliche Ausgaben bei den Rechten.

Wenn ich nun als backupuser chmod go-w $HOME mache, sieht es bei beiden gleich aus und ich kann auch ssh mit Keys machen.

 

[Nomad]

Bei mir hat das ausgereicht damit es funktioniert.

Was passiert wenn du als ein anderer Nutzer einloggst? Wie sehen da die Permissions für backupuser aus?

Offenbar überprüft SSH Server die "sichere" Ablage von authorized_keys. Wenn die Permissions zulassen, dass ein non-root User sie manipulieren kann ignoriert er sie.

Was passiert wenn du authorized_key für root konfigurierst? Soweit ich sehen konnte wird ~root mit Permission 0700 angelegt und das bleibt auch so. Das sollte auf jeden Fall das "springende" Permission Problem eliminieren.