Synology NAS - More SSH Loveliness - Permissions and ACLs

Following on from my earlier posts: -

Synology NAS - From My Mac, Via SSH

Synology NAS - Broke SSH but Telnet saved me

I've gone a few steps further in my understanding.

I've now got to a point where I can access the NAS using a user other than root or admin.

Having created a new user via the Web UI ( DaveHay ) which was a member of the users and administrators groups, I went through the same steps as before: -

Client-side ( macOS )

Generate a public/private key

ssh-keygen -t rsa -b 4096 -f foobar -N passw0rd

Generating public/private rsa key pair.
Your identification has been saved in foobar.
Your public key has been saved in foobar.pub.
The key fingerprint is:
SHA256:w7rpoqt07lMZNhT9GVdCOpRKEunRq9+zGb6+YHl8kC4 davidhay@Davids-GhostRider-4.local
The key's randomart image is:
+---[RSA 4096]----+
|     o*  .oo..   |
|     = +.o...    |
|    o + +o+      |
|     = + oo      |
|    . = So       |
|     + .+..      |
| . .. oE.= .     |
|. o.. .+=o+      |
|..+=.o+ .B=      |
+----[SHA256]-----+

Copy the public key to the clipboard

pbcopy < foobar.pub 

Server-side ( Synology )

Logged in as admin

ssh admin@diskstation

admin@diskstation's password: 

Switched to the root user

admin@DiskStation:~$ sudo bash
Password: 

Switched to the DaveHay user

su - DaveHay

( NOTE the above steps are required because I deliberately didn't give the user a password, as I only ever want to authenticate via a public/private key )

Create .ssh subdirectory

mkdir ~/.ssh

Create authorised keys file in .ssh

vi ~/.ssh/authorized_keys

Add public key from clipboard

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCz6Nd1Zugpjbsaz0ceF8WK5ps7SExiV6bR3ITtufFd0jp+ZyIhGJY+iRMzqslGEGcrYHGWzZRUGwq+dT4rikm/3yI2usHUI7TE2pFXS0SVI0jdsSp76Yos7lTVdcRJVlVaXG6nCKPYY3zfLrgmNXwDArYUHkVotBuKeF19lXR5Uu5DvxWUCsXz1APuRaX6oylmmk9QgZGClqdn4rrPjzKguwSZpUIOFRIfIbJiEIKvfu1vrEF45QlAoxvx4BQ0Mqew7Dv9Nt/s5ByGs7w/YHwJiWDpbGx0KCMiaeuwLjuj8N/dxfh6DIllqKzEXRCniftU6hXDULKLLoQx8WZoU90kvRLob27SjcVDrdM6C1Q0yQ2OGY0/OjKl2QjFk99LmZbCvLA5hb46eQBJviM1l9BBlf6eBq0qQtADKGV2UfZb43Z32rYObyqPqQjnfYiAk1CdECtJUCCGPdXbviPfDOYKaXgseBCnLNpnAislcmvI0YsuKKTo3xz16PFvhyJel+5EEbIpZaRQTQNDPjpXqr2pzhP5vcKuh09Z/w7lFZ0oRP47SACryYgbQzTowDthJ135kW00AsGMMEP9Yz2HjqQLdZZv0NL0KZgGIxaFHXpshPuCOWK3MmYtEqoJtcSDr++JtLU+/59/b3N+BqZxYuFSoOEUMhiee3k7VMq1ZNT5/Q== davidhay@Davids-GhostRider-4.local

Client-side ( macOS )

Attempt to connect using private key

ssh -i ~/foobar DaveHay@diskstation

which immediately prompted me for a password: -

DaveHay@diskstation's password: 

As before, I went back into the Synology, and updated the directory / file permissions for the newly created .ssh subdirectory

Server-side ( Synology )

( As DaveHay, having logged on as admin and switched user via su - DaveHay )

Check current state

ls -al -R ~

.:
total 20
drwxrwxrwx+ 3 DaveHay users 4096 Jan  5 18:40 .
drwxrwxrwx+ 7 root    root  4096 Jan  5 18:32 ..
drwxrwxrwx+ 2 DaveHay users 4096 Jan  5 18:40 .ssh
-rwxrwxrwx+ 1 DaveHay users  669 Jan  5 18:40 .viminfo

./.ssh:
total 12
drwxrwxrwx+ 2 DaveHay users 4096 Jan  5 18:40 .
drwxrwxrwx+ 3 DaveHay users 4096 Jan  5 18:40 ..
-rwxrwxrwx+ 1 DaveHay users  762 Jan  5 18:40 authorized_keys

Set the .ssh subdirectory to 700

chmod 700 ~/.ssh

Set the authorized_keys file to 644 

chmod 644 ~/.ssh/authorized_keys

Source: http://ss64.com/bash/chmod.html

Check new state

ls -al -R ~

/var/services/homes/DaveHay:
total 20
drwxrwxrwx+ 3 DaveHay users 4096 Jan  5 18:40 .
drwxrwxrwx+ 7 root    root  4096 Jan  5 18:32 ..
drwx------  2 DaveHay users 4096 Jan  5 18:40 .ssh
-rwxrwxrwx+ 1 DaveHay users  669 Jan  5 18:40 .viminfo

/var/services/homes/DaveHay/.ssh:
total 12
drwx------  2 DaveHay users 4096 Jan  5 18:40 .
drwxrwxrwx+ 3 DaveHay users 4096 Jan  5 18:40 ..
-rw-r--r--  1 DaveHay users  762 Jan  5 18:40 authorized_keys

Attempt to connect using private key

ssh -i ~/foobar DaveHay@diskstation

which immediately prompted me for a password: -

DaveHay@diskstation's password: 

:-(

I added some debugging: -

ssh -v -i ~/foobar DaveHay@diskstation

which showed: -

…

debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: foobar
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
DaveHay@diskstation's password: 
…

ssh -vv -i ~/foobar DaveHay@diskstation

which showed: -

…

debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: foobar
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
DaveHay@diskstation's password: 
...

ssh -vv -i ~/foobar DaveHay@diskstation

…

debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: foobar
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
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
DaveHay@diskstation's password: 

…

Something I read online made me think about extended attributes, over and above the usual Unix permissions.

I re-visited the current state: -

ls -al -R ~

/var/services/homes/DaveHay:
total 20
drwxrwxrwx+ 3 DaveHay users 4096 Jan  5 18:40 .
drwxrwxrwx+ 7 root    root  4096 Jan  5 18:32 ..
drwx------  2 DaveHay users 4096 Jan  5 18:40 .ssh
-rwxrwxrwx+ 1 DaveHay users  669 Jan  5 18:40 .viminfo

/var/services/homes/DaveHay/.ssh:
total 12
drwx------  2 DaveHay users 4096 Jan  5 18:40 .
drwxrwxrwx+ 3 DaveHay users 4096 Jan  5 18:40 ..
-rw-r--r--  1 DaveHay users  762 Jan  5 18:40 authorized_keys

Yes, it was the additional plus character that made me wonder; +

As root I checked the permissions for the DaveHay user: -

ls -ale /volume1/homes/DaveHay/

total 20
drwx------+ 3 DaveHay users 4096 Jan  5 18:40 .
 [0] user:DaveHay:allow:rwxpdDaARWcCo:fd-- (level: 0)
 [1] user:DaveHay:allow:rwxpdDaARWc--:fd-- (level: 1)
 [2] user::allow:rwxpdDaARWc--:fd-- (level: 1)
 [3] user::allow:rwxpdDaARWc--:fd-- (level: 1)

d--x--x--x+ 7 root    root  4096 Jan  5 18:32 ..
drwx------  2 DaveHay users 4096 Jan  5 18:40 .ssh
-rwx------+ 1 DaveHay users  669 Jan  5 18:40 .viminfo
 [0] user:DaveHay:allow:rwxpdDaARWcCo:---- (level: 1)
 [1] user:DaveHay:allow:rwxpdDaARWc--:---- (level: 2)
 [2] user::allow:rwxpdDaARWc--:---- (level: 2)
 [3] user::allow:rwxpdDaARWc--:---- (level: 2)

and used chmod to recursively set ALL the permissions on the DaveHay user's home directory: -

chmod -R 700 /volume1/homes/DaveHay/

which removes the special attributes ( I think these may be the ACLs added by the NAS itself when I created the new user ), and validated: -

ls -ale /volume1/homes/DaveHay/

total 20
drwx------  3 DaveHay users 4096 Jan  5 18:40 .
d--x--x--x+ 7 root    root  4096 Jan  5 18:32 ..
drwx------  2 DaveHay users 4096 Jan  5 18:40 .ssh
-rwx------  1 DaveHay users  669 Jan  5 18:40 .viminfo

In other words, the extended attributes for the user have gone, apart from the parent directory ( /volume1/homes ) which is fine.

I re-tested my SSH connection: -

ssh -i foobar DaveHay@diskstation

Enter passphrase for key 'foobar': 
DaveHay@DiskStation:~$ 

In other words, I'm only now being presented with a request for the passphrase for the private key, rather than the password for the DaveHay user.

So, it was a long journey, but an enjoyable one :-)

As ever, #LifeIsGood