SSH RSA-key login

Any questions about the Command Line Interface can be placed here!
Forum rules
Synology Community is the new platform for the enthusiasts' interaction, and it will soon be available to replace the Forum.
lvx
I'm New!
I'm New!
Posts: 3
Joined: Sun Apr 03, 2016 6:07 pm

SSH RSA-key login

Unread post by lvx » Sun Apr 03, 2016 6:21 pm

Hi All,

I'm running into a ssh login problem. I want to login to my box with a key-pair.
The Synology is running DSM 6.0-7321 and some how I can't login with the keys it keeps asking for a password.

The client is OS-X and the public key does work because I use it to login to my other linux box.

The disk station has the public key in the ~/.ssh folder in the authorised_keys file. .ssh = 700 and authorised_key = 600.

Here is the output from the ssh login from OS-X in verbose mode:

Code: Select all

OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to syno-box [192.168.xxx.xxx] port xx.
debug1: Connection established.
debug1: identity file /Users/linux-user/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/linux-user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/linux-user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/linux-user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/linux-user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/linux-user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/linux-user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/linux-user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to syno-box:xx as 'linux-user'
debug3: put_host_port: [syno-box]:xx
debug3: hostkeys_foreach: reading file "/Users/linux-user/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/linux-user/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys from [syno-box]:xx
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,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: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
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 
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:kem0XNvoWYFLdZ55G7Dp7zr93drCwEqVjkRePa84ld0
debug3: put_host_port: [192.168.xxx.xxx]:xx
debug3: put_host_port: [syno-box]:xx
debug3: hostkeys_foreach: reading file "/Users/linux-user/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/linux-user/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys from [syno-box]:xx
debug3: hostkeys_foreach: reading file "/Users/linux-user/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/linux-user/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys from [192.168.xxx.xxx]:xx
debug1: Host '[syno-box]:xx' is known and matches the ECDSA host key.
debug1: Found key in /Users/linux-user/.ssh/known_hosts:5
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: /Users/linux-user/.ssh/id_rsa (0x7feb3b600270),
debug2: key: /Users/linux-user/.ssh/id_dsa (0x0),
debug2: key: /Users/linux-user/.ssh/id_ecdsa (0x0),
debug2: key: /Users/linux-user/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred 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: /Users/linux-user/.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: /Users/linux-user/.ssh/id_dsa
debug3: no such identity: /Users/linux-user/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/linux-user/.ssh/id_ecdsa
debug3: no such identity: /Users/linux-user/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/linux-user/.ssh/id_ed25519
debug3: no such identity: /Users/linux-user/.ssh/id_ed25519: 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
Somehow it keeps throwing me back.

Underneed is the output from: grep -v "^$" /etc/ssh/sshd_config | grep -v "^#"

Code: Select all

PubkeyAuthentication yes
AuthorizedKeysFile	.ssh/authorized_keys
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
Can anyone asset me on this, this is quite annoying.

lvx
I'm New!
I'm New!
Posts: 3
Joined: Sun Apr 03, 2016 6:07 pm

Re: SSH RSA-key login

Unread post by lvx » Mon Apr 04, 2016 7:36 am

Hi All,

I've just found that on an other diskstation whith DSM 6 on it, it's possible to login with a key pair. But ONLY the admin user, and NOT root or other users.
The thing is that this diskstation is upgraded from 5 to 6. And the other one has a clean install of 6.

I've did a config check between the the two and made them equal (just to be sure) after the config edit's I did a reboot (just to be sure). but still I can't login with a key.

Why is this so hard to setup????

lvx
I'm New!
I'm New!
Posts: 3
Joined: Sun Apr 03, 2016 6:07 pm

Re: SSH RSA-key login

Unread post by lvx » Tue Apr 05, 2016 1:37 pm

Keep replying myself :)

But for those who ever come across this problem.

I did a debug on the server side of the sshDaemon; "/bin/sshd -d -p xxx", where xxx is an alternative port and -d is for debug.

There I discovered that it was an folder rights issue, to my suprise actually. But after an offensive testing I discovered it was on the users home folder itself. Not on the .ssh or authorized_keys.
The users home folder ~/ is not allowed to be writable to group and other, "chmod 755 /volume1/homes/user: should do the trick.

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

slyman
I'm New!
I'm New!
Posts: 3
Joined: Sun Jun 12, 2016 6:46 am

Re: SSH RSA-key login

Unread post by slyman » Wed Jun 29, 2016 12:45 pm

Thanks for replying to yourself. That was exactly my problem.

CarrollLewis
I'm New!
I'm New!
Posts: 3
Joined: Thu Jun 23, 2016 8:25 pm

Re: SSH RSA-key login

Unread post by CarrollLewis » Sun Jul 17, 2016 8:14 pm

Thanks for replying to yourself and keeping us all updated. Your solution worked for me.

EdnamJames
I'm New!
I'm New!
Posts: 1
Joined: Wed Jul 27, 2016 6:25 pm

Re: SSH RSA-key login

Unread post by EdnamJames » Wed Jul 27, 2016 6:40 pm

Works for me, Thanks! I've been trying to work this out for a while and was on the verge of giving up.

Empyreal
I'm New!
I'm New!
Posts: 4
Joined: Sat Mar 19, 2016 6:10 am

Re: SSH RSA-key login

Unread post by Empyreal » Thu Jul 28, 2016 1:56 am

lvx wrote:Keep replying myself :)

But for those who ever come across this problem.
Really happy that you have a habit of talking to yourself! :)
lvx wrote:There I discovered that it was an folder rights issue, to my suprise actually. But after an offensive testing I discovered it was on the users home folder itself. Not on the .ssh or authorized_keys.
The users home folder ~/ is not allowed to be writable to group and other, "chmod 755 /volume1/homes/user: should do the trick.
Easier than that.. if you're in the directory at the time, just do a "chmod 755 ."

My SSH keys worked fine until I added my username to the administrators group. I tested it several times, removing my user, adding it again, etc. Only when the user was part of the administrators group would it ask me for the password.

Weird. But a BIG THANK YOU for writing this and following up on your own missives.

Cheers!

bvc
I'm New!
I'm New!
Posts: 7
Joined: Sat Aug 13, 2016 11:32 pm

Re: SSH RSA-key login

Unread post by bvc » Sun Aug 14, 2016 8:45 am

Thanks for this helpful thread!

Logging in as root works for me with a key (with a password apparently no more possible directly, only via sudo; but with a key it works). However, strangely enough, I cannot get it to work with the actual admin user. I keep being asked for the password. chmod 755 (or even 777) the home directory did not help.

I also tried removing the affected user from the administrators group, as suggested in the last post, but the synology won't let me do it...

Running the most recent DSM 6.0.1 Update 2 here.

willrun4fun
I'm New!
I'm New!
Posts: 2
Joined: Sat Mar 12, 2016 11:59 am

Re: SSH RSA-key login

Unread post by willrun4fun » Sun Sep 11, 2016 12:01 pm

I am having this issue as well even after the above fix.

MrDC
Student
Student
Posts: 68
Joined: Mon Dec 24, 2012 2:12 pm

Re: SSH RSA-key login

Unread post by MrDC » Mon Oct 03, 2016 3:44 pm

DSM 6.0.2
Can confirm: admin auth with pubkey is not working - "server refused our key"
For root works well.

Why it happens:

Code: Select all

PAM: setting PAM_TTY to "ssh"
userauth-request for user admin service ssh-connection method publickey          [preauth]
attempt 1 failures 0 [preauth]
test whether pkalg/pkblob are acceptable [preauth]
temporarily_use_uid: 1024/100 (e=0/0)
------------------------------------------------------------------------------------------------------------------------------- <<<<<<<<<< Look here
trying public key file /var/services/homes/admin/.ssh/authorized_keys
Could not open authorized keys '/var/services/homes/admin/.ssh/authorized_keys': Permission denied
-------------------------------------------------------------------------------------------------------------------------------
How to fix for user admin (in my case it work well even with StrictModes in sshd conf):

1. Check if your pubkey is ok: it's strange but sometimes during copy/paste something happens and it's not working:

Code: Select all

ssh-keygen -l -f /var/services/homes/admin/.ssh/authorized_keys
2.

Code: Select all

chmod 755 /var/services/homes/admin
3.
a.

Code: Select all

chown admin:users /var/services/homes/admin/.ssh
b.

Code: Select all

chmod 700 /var/services/homes/admin/.ssh
4.
a.

Code: Select all

chown admin:users /var/services/homes/admin/.ssh/authorized_keys
b.

Code: Select all

chmod 644 /var/services/homes/admin/.ssh/authorized_keys

alistairswanson
I'm New!
I'm New!
Posts: 1
Joined: Tue Nov 01, 2016 10:09 pm

Re: SSH RSA-key login

Unread post by alistairswanson » Tue Nov 01, 2016 10:17 pm

lvx wrote:Keep replying myself :)

But for those who ever come across this problem.

I did a debug on the server side of the sshDaemon; "/bin/sshd -d -p xxx", where xxx is an alternative port and -d is for debug.

There I discovered that it was an folder rights issue, to my suprise actually. But after an offensive testing I discovered it was on the users home folder itself. Not on the .ssh or authorized_keys.
The users home folder ~/ is not allowed to be writable to group and other, "chmod 755 /volume1/homes/user: should do the trick.

Error: Authentication refused: bad ownership or modes for directory /volume1/homes/xxxxxx
Thanks for this; I just came to the conclusion i'd have to do that, when I found your post :D

dlakatos847
I'm New!
I'm New!
Posts: 1
Joined: Mon Nov 21, 2016 8:41 pm

Re: SSH RSA-key login

Unread post by dlakatos847 » Mon Nov 21, 2016 8:42 pm

lvx wrote:Keep replying myself :)

But for those who ever come across this problem.

I did a debug on the server side of the sshDaemon; "/bin/sshd -d -p xxx", where xxx is an alternative port and -d is for debug.

There I discovered that it was an folder rights issue, to my suprise actually. But after an offensive testing I discovered it was on the users home folder itself. Not on the .ssh or authorized_keys.
The users home folder ~/ is not allowed to be writable to group and other, "chmod 755 /volume1/homes/user: should do the trick.

Error: Authentication refused: bad ownership or modes for directory /volume1/homes/xxxxxx
This one solved my problem. Thanks so much.

cyberious
I'm New!
I'm New!
Posts: 5
Joined: Fri Jun 16, 2017 5:38 am

Re: SSH RSA-key login

Unread post by cyberious » Fri Jun 16, 2017 5:06 pm

lvx wrote: The users home folder ~/ is not allowed to be writable to group and other, "chmod 755 /volume1/homes/user: should do the trick.
Thanks this was exactly the last piece I needed, typical Linux admin but I didn't even think that my home directory wouldn't be able to be accessed by SSHD. :D

slimgym
Trainee
Trainee
Posts: 14
Joined: Sun Mar 02, 2014 10:06 pm

Re: SSH RSA-key login

Unread post by slimgym » Mon Feb 26, 2018 12:34 am

Thanks for all these tips; still no joy for me but I used debug "sudo /usr/bin/sshd -p 2222 -d" and ssh'd in with -vvv on port 2222.

My problem was as simple as not spotting the filename in ~/.ssh should be authorized_keys however as a Brit I had spelt it authorised_keys ... in case this helps anyone else. These things are hard to spot even though it is actually that in sshd_config.

Also if you shut yourself out (as I had done at one point) going in through DSM and changing the ssh security level re-writes /etc/ssh/sshd_config.

User avatar
john.doe2
Beginner
Beginner
Posts: 24
Joined: Tue Nov 11, 2014 12:45 pm

Re: SSH RSA-key login

Unread post by john.doe2 » Fri May 04, 2018 4:36 pm

lvx wrote:Keep replying myself :)
There I discovered that it was an folder rights issue, to my suprise actually. But after an offensive testing I discovered it was on the users home folder itself. Not on the .ssh or authorized_keys.
The users home folder ~/ is not allowed to be writable to group and other, "chmod 755 /volume1/homes/user: should do the trick.

Error: Authentication refused: bad ownership or modes for directory /volume1/homes/xxxxxx
Thanks for the info; worked for me, too. However, the chmod command overwrites my previous permission settings and what's even more important: imho this is an essential security risk when you're operating a productive server in an environment where one user might not only access, but also modidy another user's data.

Isn't there a safe way of achieving key-based SSH login??

Post Reply

Return to “Command Line Interface”