SSH: “Server refused our key” with no reason

key-authenticationpublic-key-authenticationputtyputtygenssh

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: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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.

Best Answer

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

Related Question