5

I am running a CentOS 6.5 machine remotely via SSH. I use RSA keys and have disabled password authentication. The problem that I am having is that whenever I add a new user and want him/her to log in via SSH, they are denied access.

At first this seemed like a simple problem. Theses are what I have already tried:

  • Checked the pub key for obvious errors
  • Ensured the right permissions on authorized_keys and ~/.ssh
  • Made sure they're in the AllowUsers list in ssh_config
  • Checked firewall permissions
  • Made sure their private key is being used
  • Restarted SSHD

Here is what I have set in sshd_config:

PermitRootLogin no
AllowUsers keving moman muser

And this is what my log is telling me:

Login attempted when not in AllowUsers list:
    muser : 3 Time(s)
    root : 127 Time(s)

Why is SSH not allowing login while the AllowUsers list obviously lists muser? Is there another place where this could be set?

UPDATE: I attempted a login to that account on my machine after adding my pub key to the user's authorized_keys file with the verbose flag -v. These are the results (with a fake IP and server host key for security reasons):

$ ssh -v mattm@111.111.111.111
OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Reading configuration data /c/Users/[user]/.ssh/config
debug1: Connecting to 111.111.111.111 [111.111.111.111] port 22.
debug1: Connection established.
debug1: identity file /c/Users/[user]/.ssh/id_rsa type 1
debug1: identity file /c/Users/[user]/.ssh/id_rsa-cert type -1
debug1: identity file /c/Users/[user]/.ssh/id_dsa type -1
debug1: identity file /c/Users/[user]/.ssh/id_dsa-cert type -1
debug1: identity file /c/Users/[user]/.ssh/id_ecdsa type -1
debug1: identity file /c/Users/[user]/.ssh/id_ecdsa-cert type -1
debug1: identity file /c/Users/[user]/.ssh/id_ed25519 type -1
debug1: identity file /c/Users/[user]/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA [censored]
debug1: Host '111.111.111.111' is known and matches the RSA host key.
debug1: Found key in /c/Users/[user]/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /c/Users/[user]/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /c/Users/[user]/.ssh/id_dsa
debug1: Trying private key: /c/Users/[user]/.ssh/id_ecdsa
debug1: Trying private key: /c/Users/[user]/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
gillytech
  • 329
  • 1
  • 3
  • 12
  • 2
    Did you restart sshd? – Michael Hampton Oct 21 '14 at 01:05
  • If you have a Linux client, what happens if you turn on verbose logging (-v). Similarly, are you in a position to run sshd in the foreground with logging ? Lastly, did you restart SSH after modifying AllowUsers ? – davidgo Oct 21 '14 at 01:06
  • @davidgo I updated the question with the putput you mentioned. – gillytech Oct 21 '14 at 02:10
  • @MichaelHampton Sure did. – gillytech Oct 21 '14 at 02:11
  • Can you post the output from /var/log/secure through a login attempt? – toppledwagon Oct 21 '14 at 04:13
  • @toppledwagon This was the ticket, log said bad permissions. However .ssh was set to 700 and authorized_keys was set to 600, the problem came from the home directory itself having group write permissions. That's another problem, though. I was able to log in after this. Add this as an answer and I will accept it. Thanks! – gillytech Oct 21 '14 at 04:26
  • Check your /var/log/secure for clues. – toppledwagon Oct 21 '14 at 04:27
  • Check this post if your log comes up with permission issues http://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/ – gillytech Oct 21 '14 at 04:29

2 Answers2

13

As @toppledwagon suggests in the comments to my question, I checked /var/log/security and sure enough there was an entry for bad permissions on the ~/.ssh/authorized_keys tree including the home directory.

After making these edits I was able to log in to the user's account via ssh with RSA keys:

$ chmod g-w /home/your_user
$ chmod 700 /home/your_user/.ssh
$ chmod 600 /home/your_user/.ssh/authorized_keys

Ref: http://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

After adjusting these permissions I was able to log in. It was interesting to note that I had the .ssh dir and authorized_keys file already set to 700 and 600 respectively. For some reason the home directory was not set properly.

Thanks to all who helped in the comments.

gillytech
  • 329
  • 1
  • 3
  • 12
3
  1. In /etc/ssh/sshd_config add the group of your user to AllowGroups.
  2. Restart sshd service sshd restart
ACV
  • 201
  • 2
  • 3