non root ssh keys

Question

I'm having issues setting up a different CentOS account with its own pair of SSH keys. I have created the required files but when connecting with Putty it says Connection refused, here's the putty log:

2013-03-31 23:09:14 Looking up host "XXX.XXXXXX.XXXXX"
2013-03-31 23:09:14 Connecting to XX.XX.XXX.XXX port 22
2013-03-31 23:09:14 Server version: SSH-2.0-OpenSSH_5.3
2013-03-31 23:09:14 Using SSH protocol version 2
2013-03-31 23:09:14 We claim version: SSH-2.0-PuTTY_Release_0.62
2013-03-31 23:09:14 Doing Diffie-Hellman group exchange
2013-03-31 23:09:15 Doing Diffie-Hellman key exchange with hash SHA-256
2013-03-31 23:09:15 Host key fingerprint is:
2013-03-31 23:09:15 ssh-rsa XXXX XX:6s:18:67:a3:39:39:95rn:21:p1:9b:12:4b:1p:24
2013-03-31 23:09:15 Initialised AES-256 SDCTR client->server encryption
2013-03-31 23:09:15 Initialised HMAC-SHA1 client->server MAC algorithm
2013-03-31 23:09:15 Initialised AES-256 SDCTR server->client encryption
2013-03-31 23:09:15 Initialised HMAC-SHA1 server->client MAC algorithm
2013-03-31 23:09:15 Reading private key file "C:\Users\XXXXX\Desktop\SSH-Key.ppk"
2013-03-31 23:09:15 Offered public key
2013-03-31 23:09:15 Server refused our key
2013-03-31 23:09:15 Using SSPI from SECUR32.DLL
2013-03-31 23:09:15 Attempting GSSAPI authentication
2013-03-31 23:09:16 GSSAPI authentication request refused
2013-03-31 23:09:16 Disconnected: No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

Answer 1

Take a look at this superuser.com question along with it's answers: putty 0.61: why do I see “Access Denied” message after I enter my login id?

Sounds like an issue with your particular version of PuTTY. Make sure you're using 0.62 or higher.

• http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/gssapi-access-denied.html

This appears to be a bug with version 0.61 of PuTTY.

summary: Spurious "Access denied" printed in the PuTTY window after GSSAPI failure

class: bug: This is clearly an actual problem we want fixed.

difficulty: fun: Just needs tuits, and not many of them.

priority: high: This should be fixed in the next release.

absent-in: 0.60 present-in: 0.61 fixed-in: r9232 0.62

Answer 2

The important part is:

2013-03-31 23:09:15 Offered public key
2013-03-31 23:09:15 Server refused our key

That means: the client sent the public key, but server rejected it for some reason. To find out why the server rejected the key, you need to look into the server's log, typically /var/log/secure or /var/log/auth.log on Linux systems.

The most common reason for such rejection is that users (other than the one you're logging in as) have write access to one or more of the following:

• the ~/.ssh/authorized_keys file
• the ~/.ssh directory
• the user's home directory.

For new users of SSH, it might seem counter-intuitive that SSH key authentication stops working if you give the relevant files or directories too much access. This is a security feature: if the list of authorized SSH keys is writable by anyone other than the owner of the user account, a malicious user might just drop in his/her key and would then have unrestricted access to that account. In this situation, sshd simply stops accepting key authentication for that user at all until the permission problem is fixed (and the list of authorized keys hopefully checked for tampering).