Passwordless ssh

Currently reading
Passwordless ssh

16
13
NAS
RS1219+, DS416, DS414, DS220+, DS218j, RS1221+
Operating system
  1. Linux
  2. Windows
Mobile operating system
  1. Android
Hello,

This is my second post, which is related to my problem. I apologize for inconvenience having two questions active the same time, but my problem is urgent.

I want to login to my Diskstation through ssh without asking password in order to use rsync to synchronize two diskstations.

I am aware how to do this on numerous Linux systems, and i did it in the past on three other Diskstations, one of them is the destination machine.

I read a plethora of guides about how to do it in DSM especially, but all of them failed.
Some of the guides propose to change the following properties of /etc/ssh/sshd_config file.
  • RSAAuthentication yes
  • PubkeyAuthentication yes
  • AuthorizedKeysFile .ssh/authorized_keys

At first the other DSMs where i am able to shh without password, they haven't those properties changed, and at second when i am enabling these properties i am loosing the ssh connectivity at all. I have to telnet and comment these properties and restart sshd, in order to have access to ssh.

Do you know any guide that works to check my configuration?

Thanks in advance
 
Hello,

This is my second post, which is related to my problem. I apologize for inconvenience having two questions active the same time, but my problem is urgent.

I want to login to my Diskstation through ssh without asking password in order to use rsync to synchronize two diskstations.

I am aware how to do this on numerous Linux systems, and i did it in the past on three other Diskstations, one of them is the destination machine.

I read a plethora of guides about how to do it in DSM especially, but all of them failed.
Some of the guides propose to change the following properties of /etc/ssh/sshd_config file.
  • RSAAuthentication yes
  • PubkeyAuthentication yes
  • AuthorizedKeysFile .ssh/authorized_keys

At first the other DSMs where i am able to shh without password, they haven't those properties changed, and at second when i am enabling these properties i am loosing the ssh connectivity at all. I have to telnet and comment these properties and restart sshd, in order to have access to ssh.

Do you know any guide that works to check my configuration?

Thanks in advance
First, two things to keep in mind :

  • By default, root is not allowed to connect, you need to connect with another user and use sudo su (type the password of the user you are connected with, not the root password).
  • Only members of the administrators group are allowed to connect by SSH. However, even non-administrators can use the rsync service.
Public key authentification is disabled by default, you will need to enable it :

  • make sure the SSH service is enabled in Control panel > Terminal & SNMP > Enable SSH service
  • set up a user account if you don’t already have one (mine will be called foaly) and temporarily add it to the administrator's group using Control panel > User > foaly > Edit > User groups)
  • log into the NAS via SSH : ssh foaly@[nas-ip] in a Linux terminal or use Putty on Windows
  • log into a root session: sudo su
  • edit the SSH service config : vim /etc/ssh/sshd_config
  • uncomment the lines PubkeyAuthentication yes and AuthorizedKeysFile .ssh/authorized_keys (make sure not to change anything else, otherwise you could lock yourself out of SSH)
  • restart the SSH service, either using synoservicectl --restart sshd or by disabling and re-enabling the SSH service in Control panel > Terminal &SNMP
  • if you added your user to the administrators group at the beginning of this procedure, you can now remove it form the group (except if this is the same user you want to add keys to, keep reading)
Now that public key authentification is enabled, you need to exchange keys for each host and user that need to be able to automatically authenticate. Let’s assume you want to allow a remote server to authenticate with the user backup :


  • add the backup user to the administrators group
  • connect to the server and generate a key pair if don’t have one already: ssh-keygen -t rsa
  • copy the public key to the NAS : ssh-copy-id backup@[nas-ip] (you will need to enter the password of the backup user)
  • this is important: connect to the NAS by SSH and check the file's permissions:
    • chmod 0711 ~
    • chmod 0711 ~/.ssh
    • chmod 0600 ~/.ssh/authorized_keys
  • now, the authentification should work: from the server, try to log in to the NAS (ssh backup@nas-ip) and check that it logs in without requiring a password
  • if you only want to use rsync with this user (not SSH) you can now remove the backup user from the administrators group
 
Upvote 0
Thanks a lot @Rusty for your guide.

Unfortunately i have followed those instructions enough times, with some variations. They work except of the passwordless part.

Public key authentification is disabled by default, you will need to enable it :
Is there any specific place to enable it apart of Terminal&SMTP and sshd_config?
 
Upvote 0
Thanks a lot @Rusty for your guide.

Unfortunately i have followed those instructions enough times, with some variations. They work except of the passwordless part.


Is there any specific place to enable it apart of Terminal&SMTP and sshd_config?
Not that I am aware of. This method works for me, tested and confirmed.
 
Upvote 0
This is what I have in my sshd_config that is working for me, if I remove all of my commented lines here is what I am left with (whole config file attached)

Code:
StrictModes no
RSAAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
AllowTcpForwarding no
UsePrivilegeSeparation sandbox        # Default for new installations.
UseDNS no
ChrootDirectory none
Subsystem       sftp    internal-sftp -f DAEMON -u 000
Match User root
    AllowTcpForwarding yes
Match User admin
    AllowTcpForwarding yes
Match User anonymous
    AllowTcpForwarding no
    GatewayPorts no

and the matching RSA pubkey installed in the corresponding Syno User's ~/.ssh/authorized_keys by doing vim ~/.ssh/authorized_keys
1631284962775.png


  • My home directory, .ssh dir and authorized_keys files are permissioned as follows
    • chmod 0711 ~
    • chmod 0711 ~/.ssh
    • chmod 0611 ~/.ssh/authorized_keys
1631285382179.png


on the windows side, I have these in %userProfile%/.ssh
1631285632579.png


If I remember correctly, it was crucial that the Windows side of the key storage be properly permissioned as well, and I had to make sure that the .ssh folder and id_rsa file were not accessible at all by anyone except the user, "Administrators" and SYSTEM, any more would make the OpenSSH Client ignore the key as an option
1631285743553.png


I also found it useful to make a %userprofile%/.ssh/config file so I could just ssh 10.0.0.51 instead of ssh [email protected]
Code:
Host 10.0.0.51
  HostName 10.0.0.51
  User admin
  ForwardAgent yes
Note: I don't think the ForwardAgent does much for HERE, but I may have needed that part when I was separately trying to setup SSH publicKey auth from my Synology BACK to my Windows Desktop

If you are still having trouble - try running ssh [email protected] -v for MUCH more detail about the authentication process - if that isn't enough, I believe you can do -vv or -vvv as well for more detail, just be ready to read through a LOT
1631286551874.png
 

Attachments

  • sshd_config.txt
    4 KB · Views: 15
  • 1631286580165.png
    1631286580165.png
    127.8 KB · Views: 53
Upvote 0
Last edited:
Let me quote another post of mine:

https://www.synoforum.com/threads/how-to-enable-keyfile-based-auth-for-ssh-on-dsm.4687/#post-20571 said:
Lessons learned:
- there is no need to customize /etc/ssh/sshd_config. Regardless of what any tutorial says: it is not required. I just reverted all changes and it still works
- error reporting is terrible (part1): the ~ folder of the target user was not 700, the ~/.ssh folder was not 700 and ~/.ssh/authorized_keys was not 600.
- error reporting is terrible (part2): only /bin/sh and /bin/ash are allowed as login shell
- error reporting is terrible (part3): the user MUST be in the admistrators group
- ed25519 and RSA keys work

Further notes:
1. I am not sure why people add execution rights for group and others to ~/.ssh (711) and ~/ssh/authorized_keys (611), even though its not required.
2. the commented lines in /etc/ssh/sshd_config show the default values that are already implicity used - uncommenting a line, without changing its value does not affect the outcome.
-- post merged: --

Note: I don't think the ForwardAgent does much for HERE, but I may have needed that part when I was separately trying to setup SSH publicKey auth from my Synology BACK to my Windows Desktop
This is usefull if the ssh keys are loaded in pagent and forwarded within the ssh connection. This would result that the same key will be available within the active ssh session as well.

I keep my ssh keypairs in keepass + keeagent addon, which impements pagent and can be used to use Agent authentification with windows openssh or putty. This way I can push my git projects to github, without having to store the key on the NAS (or on the harddisk of my laptop).
 
Upvote 0
Any other hints on how to get keyfile ssh access working on DSM 7.0?

I've done this many times before on several older DSM models and a bunch of linux desktops, but can't get private keyfile access working on my new DS220+. Have followed the above instructions along with other similar threads on the web, without luck. Can log in using plain passwords just fine, but get a "server refused your key" when trying my private key file. Seems Synology have screwed around with sshd yet again on DSM 7.0
 
Upvote 0
This is what I have in my sshd_config that is working for me, if I remove all of my commented lines here is what I am left with (whole config file attached)

Code:
StrictModes no
RSAAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
AllowTcpForwarding no
UsePrivilegeSeparation sandbox        # Default for new installations.
UseDNS no
ChrootDirectory none
Subsystem       sftp    internal-sftp -f DAEMON -u 000
Match User root
    AllowTcpForwarding yes
Match User admin
    AllowTcpForwarding yes
Match User anonymous
    AllowTcpForwarding no
    GatewayPorts no

and the matching RSA pubkey installed in the corresponding Syno User's ~/.ssh/authorized_keys by doing vim ~/.ssh/authorized_keys
View attachment 4445

  • My home directory, .ssh dir and authorized_keys files are permissioned as follows
    • chmod 0711 ~
    • chmod 0711 ~/.ssh
    • chmod 0611 ~/.ssh/authorized_keys
View attachment 4446

on the windows side, I have these in %userProfile%/.ssh
View attachment 4447

If I remember correctly, it was crucial that the Windows side of the key storage be properly permissioned as well, and I had to make sure that the .ssh folder and id_rsa file were not accessible at all by anyone except the user, "Administrators" and SYSTEM, any more would make the OpenSSH Client ignore the key as an option
View attachment 4448

I also found it useful to make a %userprofile%/.ssh/config file so I could just ssh 10.0.0.51 instead of ssh [email protected]
Code:
Host 10.0.0.51
  HostName 10.0.0.51
  User admin
  ForwardAgent yes
Note: I don't think the ForwardAgent does much for HERE, but I may have needed that part when I was separately trying to setup SSH publicKey auth from my Synology BACK to my Windows Desktop

If you are still having trouble - try running ssh [email protected] -v for MUCH more detail about the authentication process - if that isn't enough, I believe you can do -vv or -vvv as well for more detail, just be ready to read through a LOT
View attachment 4450

For me your
"RSAAuthentication yes" did the trick!

Thank you!
 
Upvote 0
There is no need to change the sshd_config, this is my way of getting passwordless acces to DSM.

  • make sure the SSH service is enabled in Control panel > Terminal & SNMP > Enable SSH service
  • make sure your user have admin rights
  • log into the NAS via SSH: ssh admin-user@[nas-ip] in a Linux/Mac terminal or use Putty on Windows
  • log into a root session: sudo -i
  • add the following in terminal echo ADMIN-USERNAME ALL = NOPASSWD: ALL > /etc/sudoers.d/private
  • if this is succesful than open a new terminal window and Do not login to you nas!
  • just enter the following ssh-copy-id -p 22 adminuser@[nas-ip] you will see a message and asked for the password of the admin-user

After this you can login passwordless into your nas using SSH and Terminal/Putty.
This method will create a file in /etc/sudoers.d/ called private and a .ssh folder with a file called authorized_keys.

This is how I'm doing it for a couple of years now;-)
 
Upvote 0
Last edited:
As it seems this is an ongoing question, I'll add what worked for me.

fwiw, I agree with @one-eyed-king in respect of:

2. the commented lines in /etc/ssh/sshd_config show the default values that are already implicity used - uncommenting a line, without changing its value does not affect the outcome.
In my experience (tested and verified), leaving commented the 'PubkeyAuthentication yes' and 'AuthorizedKeysFile .ssh/authorized_keys' lines makes no difference.

In terms of home/.ssh dir perms, again, I would again agree in so much as; Why would you ever give 'group' or 'other' permissions to your home dir.? Major flaw.

In fact, paying attention to this now, I see Synology created all home dirs with 0777. Why would they do that? Is there no 'umask' (a.k.a. default UNIX permissions) implemented (feeds into another thread I have up at the moment)?

I personally have (for my 'admin' ssh account):
  • chmod 0700 ~
  • chmod 0700 ~/.ssh
  • chmod 0600 ~/.ssh/authorized_keys
With this config, I have stopped/started the ssh service and dbl-checked; it works. Funnily enough, backing up @Rusty above, 0711 does work on both '~' and '.ssh'. I looked at my old 918+ and it actually had my '~' home dir set as 0755, and passwordless ssh was still working; has been forever. Basically, so long as your 'admin' home dir is NOT set to 0777, then passwordless ssh seems to work. Let's ignore the security aspect of 0755 or 0711 home dir perms for now.

@Telos, I'm sorry, but that article is severely lacking in terms of the file/dir perms required to make it work.
 
Upvote 0

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

That's the way I currently use. However without using a ssh key but typing in a password.
Replies
7
Views
3,229
  • Question
Tailscale may be a better option than Synology VPN.
Replies
18
Views
2,199
Right understood. The PHP file will be executed by the web host itself so by the http user I guess.
Replies
7
Views
5,874

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads

Back
Top