I've inherited the administration of a linux box in my workplace; it was set up by a colleague who is now gone. Recently, I added a new user to the system, and tried to give her ssh access as well; the way most people who use the machine access it. This, I can't get to work.

Here's what happens:

scmb-bkobe03m:~ xzhang$ ssh -v -X -p 22 arwen@myServer
OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to myServer [152.98.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /Users/xzhang/.ssh/identity type -1
debug1: identity file /Users/xzhang/.ssh/id_rsa type 1
debug1: identity file /Users/xzhang/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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<1024<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: Host '[myServer]:22' is known and matches the RSA host key.
debug1: Found key in /Users/xzhang/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/xzhang/.ssh/identity
debug1: Offering public key: /Users/xzhang/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/xzhang/.ssh/id_dsa
debug1: No more authentication methods to try.

Now, I have of course added her public ssh-key to authorized_keys file. So I had a look in /var/log/auth.log and found

Jan  7 11:37:12 sauron sshd[5002]: User arwen from myClientMachine not allowed because not listed in AllowUsers

Which is funny since I did add her to AllowUsers:

daniel@sauron:~$ sudo more /etc/ssh/sshd_config | grep AllowUsers
AllowUsers jonathan daniel rafael simon thomas li arwen

I don't know where to go from here. Any takers?

  • 9
    have you restarted ssh service after adding user into configuration file. Jan 11, 2013 at 7:25
  • 1
    @RahulPatil it's not necessary to restart - sshd rereads it's configuration file on when it receives SIGHUP.
    – peterph
    Jan 11, 2013 at 16:37
  • 1
    @peterph yes, i means restart/reload sshd to re-read configuration file. Jan 11, 2013 at 17:55
  • 1
    There may be something else in your sshd_config that's relevant, you should post the whole file (suitable anonymized if necessary). Jan 11, 2013 at 22:39

3 Answers 3


If you're absolutely sure that you've restarted the SSH server or told it to reload its configuration file by sending it a SIGHUP…

Maybe the AllowUsers is in a Match section? If there is a previous Match directive, it might cause jonathan, arwen and the others to be only allowed in certain circumstances, as in

Match localhost PasswordAuthentication yes

# Whitelist users who may ssh in
AllowGroups admin
AllowUsers jonathan daniel rafael simon thomas li arwen

(The comment is misleading: these AllowGroups and AllowUsers directives only apply when logging in to localhost. The Match localhost directive should be moved below these.)


If you are under Ubuntu, you might face the same issue as I did. There are two service definitions /etc/init.d/ssh and /etc/init/ssh.conf . Restarting service like (old-style)

/etc/init.d/ssh restart

does nothing (and status command shows nothing). Restarting Upstart service directly like

service ssh restart

does the thing. Since OS restart helped in your case, that seems to be an issue.

Also, check that users are space-separated, and not comma-separated. SSH daemon does not show any warnings for that.

  • Note that you cannot restart ssh while logged in via ssh. No error is reported if you do this. Just the usual message is printed. This can be verified by adding the START column to htop and see that the sshd process was not just restarted. To restart ssh remotely if the server is headless, do a reboot. If server has a console (screen and keyboard), do the service ssh restart from there. Mar 6, 2020 at 2:13

A free places could be the issue.

In the sshd_config or ssh_config if it has commented AllowGroups or AllowUser, these apply to ssh remote sessions also. If you have commented PermitRemotelogin No, Change No to Yes.

"you can also comment out the statement and restart ssh see if that the problem before you go and attempt to change anything else. To comment out just add hashtag before comment

#AllowGroups Group1 <- made up group
#Allow User User1

AllowGroups Group1
AllowUser User1

Check the User Groups, make sure the user name you are attempting to use to login is in the group.

vi /etc/group

Group1:100:user1,root, etc <- If nothing is listed here then its a denie allow statement.

After any changes to sshd_config or ssh_config, You will have to restart ssh.

svcadm restart ssh

Other places to look:

vi /etc/defalut/login
vi /etc/pam.config
vi /etc/sshd_config

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .