Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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_REQUEST sent
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. 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?

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

2 Answers 2

up vote 1 down vote accepted

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.)

share|improve this answer
    
Egg, meet face. Restarting the system was all it took at this point. Many thanks for the input. –  d.ericsson Jan 14 '13 at 0:49

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
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.