SSH with no password (passwordless) on Synology DSM 5 as other (non-root) user

Question

I'm trying to ssh into my Synology disk station without a password (public key authentication), but as non-root.

When I try to ssh as root without password, it works. Following the exact same steps for another user doesn't work. It always asks for password (also, using a password works too).

I have followed every guide out there for this, but I think they're all for DSM 4.x rather than for the new 5.0 version.

SSH debug log

Here's the debug log when I try with -vvv flag:

aether@aether-desktop:~$ ssh -vvv [email protected]
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: [email protected],[email protected],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: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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,[email protected]
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,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
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
[email protected]'s password: 

Any help appreciated.

Things I've tried so far

• Check /etc/ssh/sshd_config (RSAAuthentication, PubkeyAuthentication, AuthorizedKeysFile).
• Check .ssh/* perms and ownership. Tried several combinations.
• Check HOME var in ~/.profile.
• Restarted sshd via synoservicectl --restart sshd and by restarting whole NAS.

Answer 1

I had the same problem. I run an instance of sshd in debug mode on the DiskStation using "/usr/syno/sbin/sshd -d", then I connect to it using "ssh user@DiskSation -vvv" and I got the debug info on the server:

......

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

debug1: trying public key file /var/services/homes/user/.ssh/authorized_keys

debug1: fd 5 clearing O_NONBLOCK

Authentication refused: bad ownership or modes for directory /volume1/homes/user

......

I realized that the home folder needs the right permissions too:

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

And replace with the actual username, like "user".

Finally, the problem is solved!

Answer 2

you need to chmod your home directory to 755 (synology has it at 777 by default)

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

Answer 3

As your permissions for .ssh and authorized_keys are set correct, just verify that the permissions to your home directory (/home/aether/) are set correctly (chmod 755 /home/aether/).

I could not log in with the default permissions (711) and it worked after changing the permissions.

Cheers Stephan

Answer 4

I had the same problem, double and triple checking all the above and still didn´t work. Finally, I realized that the ssh daemon was looking for the authorized_keys file in the wrong place, as there is no /home/nonrootuser directory.

You should create the path or make a symlink (those two options didn´t work for me), or what finally worked was to add those two lines in sshd_config file:

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

This way, you make sure that the key you are adding via ssh-copy-id from the client is the same that the server (synology) is offering to stablish the connection for the nonrootuser.

Answer 5

Same problem here with DSM 6.0, solved thanks to this thread on Synology forums

It seems that user home permission are too much permissive?

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

allows it to work

Answer 6

It looks very similar to that question:

https://stackoverflow.com/questions/12839106/scp-between-2-remote-hosts-without-password/12945060#12945060

I suspect that your .ssh directory or files are not having proper attributes.

Here are mine:

-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

Also, please check contents of /etc/pam.d/sshd which may put some restrictions on non-root. Just in case. This link explains PAM in case of RHEL. It may help: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/PAM_Configuration_Files.html

Here is where the issue shows its ugly head:

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

It does not accept id_rsa, and continues:

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

It gives up, and relies on password

debug1: Next authentication method: password

So now, the question is why it does not like id_rsa?

Answer 7

I had this same problem. After setting up the correct permissions on my authorized_keys, file home and .ssh directories I still wasn't able to SSH to my Diskstation.

After reading the information at techanic.net I discovered that I also had to set my login shell in my /etc/passwd file. It was set to /sbin/nologin by default. After changing it to /bin/sh I was able to SSH to my Diskstation successfully.

Answer 8

I just had this same problem with DSM 5.1 instead of 5.0. None of the solutions listed solved the issue. In my case, the permissions for /var/services/homes/<user>/.ssh/authorized_keys was not correct. Running the following solved the issue

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

Answer 9

Just to give a little background:

The problem is that the default ssh service is configured with StricModes yes, but the user homes linked to /var/services/homes/... are controlled by Synology ACLs implementation, which are too loosy for the ssh daemon.

The method proposed by most of the colleagues here (chmod 0755 /var/services/homes/<user>) works because it destroys the ACLs on the home folder. But if for whatever reason you want to recover them at a later point, you will be probably missing the right permissions. Copy then from another home folder is usually a bad idea if the other home has personal rights.

In my case, Synology 6.2 the default is that, when "Enabling User Home service" in the Control Panel -> User -> Advance (tab) -> User home (section), then the default permissions are:

# ls -l /var/services/homes/ | grep <user>
drwx--x--x+  2 <user>   users 4096 May 11 18:24 <user>

That extra '+' tells you about ACLs, which you can check like that:

# synoacltool -get /var/services/homes/<user>
ACL version: 1 
Archive: is_inherit,has_ACL,is_support_ACL 
Owner: [<user>(user)] 
--------------------- 
     [0] user:<user>:allow:rwxpdDaARWcCo:fd--  (level:0)
     [1] group:administrators:allow:rwxpdDaARWc--:fd--  (level:1)
     [2] user:user:allow:rwxpdDaARWc--:fd--  (level:1)
     [3] user::allow:rwxpdDaARWc--:fd--  (level:1)
     [4] everyone::allow:--x----------:fd--  (level:1)
     [6] owner::allow:rwxpdDaARWcCo:fdi-  (level:1)
     [7] user:<user>:allow:rwxpdDaARWcCo:----  (level:1)
     [8] user::allow:rwxpdDaARWc--:fd--  (level:1)

As a suggestion, just remove the ACL Archive settings:

# synoacltool -del-archive /var/services/homes/<user> is_inherit,has_ACL,is_support_ACL
Archive: None 

At this point, you have a home folder with a 0755 mode.

# ls -l /var/services/homes/ | grep <user>
drwxr-xr-x  2 <user>   users 4096 May 11 18:24 <user>

And then, if you have the rest (ssh public key in .ssh/authorized_keys, right permissions, etc), then you will login passwordless.

ps: I do not suggest to change default StrictMode in the ssh daemon config, since upgrades could revert this change being unnoticed and, most importantly, you can get easily blocked out.