Synology DSM – Troubleshooting SSH Access Issues

sshsynology

On my Synology (DSM 6.2.2-24922), I have 3 users:

admin (disabled ssh and login)
user1 (my new admin user, recommanded by Synology)
user2 (not admin)

I can connect throw ssh with user1 but not with user2.

I edited /etc/passwd to replace /sbin/nologin:

user1:x:1026:100:Administrator:/var/services/homes/user1:/bin/sh
user2:x:1035:100::/var/services/homes/user2:/bin/sh

I can su user2 from user1 and ls its home directory:

sudo su - user2

But ssh command always returns Permission denied:

user2@my.domain.com's password:
debug1: Authentication succeeded (password).
Authenticated to my.domain.com ([123.123.123.123]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
Permission denied, please try again.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to my.domain.com closed.
Transferred: sent 2204, received 2744 bytes, in 0.1 seconds
Bytes per second: sent 23710.3, received 29519.5
debug1: Exit status 1

Any leads?

Best Answer

To log in via ssh, the user must be in the "administrators" group. If you look at /etc/ssh/sshd_config on the Synology you will see an AllowGroups line that sets up this restriction. If you put user2 into the administrators group, they will be able to log in with ssh. Putting a user into the administrators group will automatically change their shell (the last field on their line in /etc/passwd) from /sbin/no login to /bin/bash.

My Synology sshd configuration allows a second group, "ssh_users", but I have not tested that at all.

If you play around with this, be aware that manual changes to user properties in files like /etc/passwd and /etc/group are often undone if you modify the user in DSM, and sometimes if you make apparently unrelated changes in DSM. Sometimes an upgrade will undo manual changes too.

Related Solutions

Ssh-agent forwarding and sudo to another user

As you mentioned, the environment variables are removed by sudo, for security reasons.

But fortunately sudo is quite configurable: you can tell it precisely which environment variables you want to keep thanks to the env_keep configuration option in /etc/sudoers.

For agent forwarding, you need to keep the SSH_AUTH_SOCK environment variable. To do so, simply edit your /etc/sudoers configuration file (always using visudo) and set the env_keep option to the appropriate users. If you want this option to be set for all users, use the Defaults line like this:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers for more details.

You should now be able to do something like this (provided user1's public key is present in ~/.ssh/authorized_keys in user1@serverA and user2@serverB, and serverA's /etc/sudoers file is setup as indicated above):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

Ssh – How to automate SSH login with password

Don't use a password. Generate a passphrase-less SSH key and push it to your VM.

If you already have an SSH key, you can skip this step… Just hit Enter for the key and both passphrases:

$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.

Copy your keys to the target server:

$ ssh-copy-id id@server
id@server's password:

Now try logging into the machine, with ssh 'id@server', and check-in:

.ssh/authorized_keys

Note: If you don't have .ssh dir and authorized_keys file, you need to create it first

to make sure we haven’t added extra keys that you weren’t expecting.

Finally, check to log in…

$ ssh id@server

id@server:~$

You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.

Best Answer

Related Solutions

Ssh-agent forwarding and sudo to another user

Ssh – How to automate SSH login with password

Related Topic