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 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: 

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.
  • Why do you want to do this? Wouldn't public key authentication with an unprotected key suffice? – Daniel B Mar 31 '14 at 20:59
  • Hi Daniel, that's exactly what I'm trying to achieve, but it doesn't work for non-root user. – Vlad A Ionescu Mar 31 '14 at 21:00
  • Is your client's public key present in the user's authorized_keys file? – Daniel B Mar 31 '14 at 21:02
  • Yup, I copied it with ssh-copy-id. And it's the exact same authorized_keys file (but with right perms) from root user, which works when root. – Vlad A Ionescu Mar 31 '14 at 21:04
  • Does your account have a password now? Depending on your system's security policies, users without a password may be barred from logging in. – Daniel B Apr 1 '14 at 6:22
up vote 46 down vote accepted

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!

  • 2
    Just as for you, running chmod 755 on my home directory solved this for me on DSM 6. – David Pärsson Jul 31 '16 at 17:14
  • It's always the right solution to get debug logs. Thanks! Just one addition: Call /usr/bin/sshd -p 2222 (and connect with ssh -p 2222) so it runs on a different port for the debugging - otherwise you risk losing access if you quit the ssh deamon – Alex Sep 3 '17 at 15:35

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
  • This does not show that chmod 755 /home/admin actually changed the permissions. – user20342 Aug 4 '14 at 16:36
  • Yeah, that's true. It did though, i just cobbled together the pasted example and I missed that. I'll edit the answer. – spuriousdata Aug 27 '14 at 19:31

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

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.

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]

...and now it works!

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?

  • Hi Grzegorz, the .ssh dir has perm 700 and .ssh/authorized_keys has perms 600. – Vlad A Ionescu Mar 31 '14 at 21:08
  • @VladAlexandruIonescu: I have updated my response showing other attributes, and information regarding PAM which may give you more area to test. – Grzegorz Mar 31 '14 at 21:50
  • Thanks, Grzegorz, but still no luck. I've tried the exact same perms as yours. Also had a look around /etc/pam.d/sshd, but doesn't look like anything would discriminate the root user: gist.github.com/vlad-alexandru-ionescu/e6a2ee6133c7e9e45273 . – Vlad A Ionescu Mar 31 '14 at 23:13
  • @VladAlexandruIonescu: Is this problem for all users? You wrote "for another user" which may indicate only one. Can you putty using this user login or you are login as root and then su it? – Grzegorz Apr 1 '14 at 13:47
  • Yes, for all non-root users. I can ssh/putty as any user (root or non-root). But it asks for password when non-root, even though I've added my client's public key to authorized_keys on the server. – Vlad A Ionescu Apr 1 '14 at 13:53

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.

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

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.