# SSH: “Server refused our key” with no reason

I was trying to set up a simple backup script to run automatically that would copy a file from a Windows machine to a Linux one through SSH.

As a lot of simple online tutorials suggest I used pscp with a private key generated with puttygen and placed the corresponding public key (presented in copy/paste form by putty itself) in the authorized_keys file in Linux. This seems pretty straightforward considering that it worked in 2 other windows machines to a different Linux machine, with the same configuration.

There are no connectivity issues AFAICS and the same goes for ssh, considering I'm able to log in as root to the Linux machine. The config file (sshd_config) has the AuthorizedKeysFile set to ~/.sshd/authorized_keys.

The error "Server refused our key" keeps showing up, no matter what I do... The logs don't show any authentication problems...

I'm planning to do more testing and setting the logLevel value to VERBOSE or DEBUG2 or 3 but considering the urgency of the matter and the fact that in order to actually test it on the machine I have to go through a lot of hassle considering the machine is in a place that is quite distant from my actual workplace...

### Questions

• Does anyone have any ideas?
• Has this ever happened to anyone?

It seems like this might actually be a problem related to ssh versions or something of the sorts...

I was also considering the possibility that I need to have the public key inserted in the authorized_keys file inside the user's .ssh directory (/user/.ssh/) besides having it in root's folder (doesn't make much sense because of the value of AuthorizedKeysFile in sshd_config).

I've done some teting with the ssh server's LogLevel set o VERBOSE but I could'nt retrieve the information (liability issues), so instead here goes an output/debug log from another source which seems to be displaying the same error...

Connection from 192.168.0.101 port 4288
debug1: Client protocol version 2.0; client software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug1: permanently_set_uid: 22/22
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: KEX done
debug1: userauth-request for user dcowsill service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "dcowsill"
debug1: userauth-request for user dcowsill service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: PAM: setting PAM_RHOST to "192.168.0.101"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2
debug1: userauth-request for user dcowsill service ssh-connection method publickey
debug1: attempt 2 failures 2
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2
Connection closed by 192.168.0.101


It seems like the program is trying to open the authorized_keys file with permissions from the owner, but then there is no more information on what is generating the problem. One last thing, I've checked and double-checked the file and foler permissions and they're all ok.

• Are you logging in as the user or as root? The authorized_keys needs to be updated for the actual login you are using. Eg for a user called bloggs in /home/bloggs/.ssh/authorized_keys and for a root in /root/.ssh/authorized_keys. Are you sure you copied/pasted correctly - easy enough to miss a single character when your selecting the text :-) – garethTheRed Sep 17 '14 at 13:33
• Thanks for the reply, I'm pretty sure I copied correctly, but the authorized_keys file that I changed was only the one belonging to root. I didn't change the oe that belonged to the user because, as I said, sshd_config is pointing to the file that belongs to root and not to /home/%u/.sshd/authorized_keys – besnico Sep 17 '14 at 13:50
• That will only work if root logs in. The ~ in your AuthorizedKeysFile stands for the home directory in a shell, but I'm not certain if it expands in sshd. On my CentOS 7, AuthorizedKeysFile is simply .ssh/authorized_keys - nothing before the .ssh, which always expands to the user's home directory. I suggest you remove the tilde (~) and add your key to the relevant authorized_keys file (user or root, depending on who you're logging in as). – garethTheRed Sep 17 '14 at 13:59
• I'll try it, thanks a lot for the effort @garethTheRed ;) – besnico Sep 17 '14 at 14:03

Some possible reasons I know are connected with file permissions these are mostly too wide and Particularly I can recall two reasons

1. exposing /home/user directory to more that the owner
2. .ssh and/or authorized_keys file permissions (set them to 700/600 respectively if they are more than that)

the exact reason of key is refused by starting an additional sshd server on another port with debug and non-daemon options if you have root access on the server you can run:

sudo which sshd -p 2020 -Dd


on the server

After leaving that running run ssh to it:

ssh -p 2020 -i /path/to/refusedkey


Server output will tell you the reason of refusal

• Thanks fo rthe help! I'll try that and come back with an update. By "run ssh to it" you mean running the ssh command on Windows to connect to Linux? Also on this issue, do you think this might be associated with what some other useres are saying? I only edited the [link](authorized_keys) file that belongs to root and not the one belonging to the user in question, only because sshd_config points to it specificaly and not to link – besnico Sep 17 '14 at 13:57
• on windows you can use plink utility (comes along with putty bundle) the syntax is almost the same: plink -P 2020 -i C:\path\to\refusedkey.ppk user@serverthatrunsdebugsshd your AK file location points to ~/.sshd/authorized_keys seems to point to to the root home where you put your public. otherwise it could not find the key to refuse it PS: backticks were escaped in my answer above and that has corrupted the command syntax you can use the following command to start another sshd process for debug purpose: sudo \$(which sshd) -p 2020 -Dd (sorry for poor formatting) – Tagwint Sep 17 '14 at 14:35
• Thanks for that answer. No problem lol, I also have a hard time with the formatting as you might understand by my replies :(. I understood the command, I'll try to run it and post some updates. Just out of curiosity, why the which ? From what I read it just prints the full path of the executables (sshd in my case) – besnico Sep 17 '14 at 14:50
• "which" is just a nice way to call your sshd by its full path w/o even knowing it :) – Tagwint Sep 17 '14 at 15:12
• the matter is you cant run sshd w/o specifying full path in front - that's the lmitation – Tagwint Sep 17 '14 at 15:19

some obvious check

• format of authorized_keys ssh-rsa AA...long_line_of_char comment putty gen sometime give another form.

• authorization:

• ~user/.ssh/authorized_keys is -rw-r--r--
• ~user/.ssh/ is drwx------
• ~user is not world writable.
• key sould be deployed id ~root or in ~user depending on the user you connect to.

some less obvious:

• root is not allowed to be ssh'd to. (PermitRootLogin no or comment )
• default location for authorized_keys AuthorizedKeysFile %h/.ssh/authorized_keys

• that is .ssh under ~user's home directory.
• sample custom location for authorized_keys AuthorizedKeysFile /foo/bar/authorized_keys.%h

• that is keys, are located in /foo/bar dir.
• in file authorized_keys.root for root
• in file authorized_keys.user for user, file is owned by root
• I did all of those (the format is right and permissions are adequate AFAICS, considering that otherwise I would have seen some error info inside var/log/secure) but I can't understand the last thing you're saying: do you mean I should have they public key under the authorized_keys file of both root and the user? Because the sshd_config file points to the file inside root's directory and not to the ".sshd" directory of the user attempting to log in – besnico Sep 17 '14 at 13:36
• @besnico see my edition, to wich user you pscp too ? – Archemar Sep 17 '14 at 13:54
• I did, thanks a lot for the help! I'm pscp'ing to a non-root user (although PermitRootLogin is set to yes) so that might be the problem, although AuthorizedKeysFile is set to ~/.sshd/authorized_keys – besnico Sep 17 '14 at 14:08
• Thank you so much, for the tips. I do not know why and how that happened, but I logged in to my machine to do apt-get upgrade and after that I could no longer connect with the key being refused - all happened in the matter of minutes. Turned out that ~user became world writable god knows how. When I fixed that I could login again. – Andrew Savinykh Apr 10 '16 at 23:56

Run:

sudo which sshd -p 2020 -Dd


as root in one session and in another session run:

ssh -p 2020 -i /path/to/refusedkey refusedkeyusername@hostname


Worked for me to get the reason. My userid permissions were not set to 700. I got the o/p as below

debug1: trying public key file /home/userid/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: restore_uid: 0/0
Failed publickey for userid from 172.31.2.12 port 27382 ssh2: RSA
Connection closed by 172.31.2.12 [preauth]

• turns out "sudo which sshd -p 2020 -Dd" this is a good suggestion. i did this and tunneld in the ssh the port 2020 to 127.0.0.1:2020 and connected from putty on windows to ubuntu 18. it showd " Invalid key length [preauth]" so i just made another key type. max key length is 1024. i had 2048. – Shimon Doodkin Apr 13 '19 at 20:49

In my case I have solved it by doing:

chmod 700 myuserdir/.ssh
chmod 600 myuserdir/.ssh/authorized_keys


On the windows box, instead of using puttygen to generate the rsa private key, I downloaded cygwin from cygwin.org. It offers a few packages by default. I modified the Net package to install OpenSSH. This has installed, among other things, the ssh-keygen program. So, I ran:

• ssh-keygen -t rsa and left the passcode empty
• This created the private key named id_rsa in c:/cygwin/home/myusername/.ssh
• I started puttygen and select menu option "File -> Load private key" and select your id_rsa (not the public id_rsa.pub).
• Save it in putty format clicking on the "Save Private Key" button (I called it putty.ppk)
• Start putty and select Connection -> SSH -> Auth -> Private key for authentication. Enter the putty.ppk generated.

Now I can connect without entering neither user nor password.

ok! one reason is that user home directory from passwd file is not the directory from which you want to copy the files. Only root can copy from every ware, the other users not!

for example if you want to copy from /backup directory, make sure the user you want to authenticate have the home directory set to /backup (owned by it), for scp to find the corect path to authorized_keys "/backup/.ssh/authorized_key"

second: be sure you to copy to authorized_keys file exactly the text from Putty Key Generator with "ssh-rsa AA...." to a single line. you can remove any comment like "rsa-key-xxx.." from the end. authorized_keys file must own user/group good luck!

From the debug server log you shared it looks like the key you specified on the client side just does not match any of available in /testuser/.ssh/authorized_keys .

if /testuser/.ssh/authorized_keys is the expected location you should check that there is a public key line there that matches your private key used on client side - that is if you use say, id_rsa on the client check id_rsa.pub next to it matches exactly one of the line in /testuser/.ssh/authorized_keys .

If you doubt about the location authorized_keys file on the server, you should figure out if you specify the right user name on the client side.

• thanks a lot man! The keys match, I pasted them and verified everything went correctly... I even double-checked! lol But seriously, I'm not sure if SELinux is enabled in the machine, could that be the problem? – besnico Sep 23 '14 at 10:06