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 am trying to create new users using useradd command using root credentials it is getting created properly but when I log in with the newly created user with its credentials using a PuTTY Console, I am able to enter the username but when I give the password, it hangs there for a long time until the PuTTY window session timeout happens and the window is closed. However when I use root credentials, it quickly enters the session.

I tried checking the AllowUsers under file /etc/ssh/sshd_config but I didn't find any matching entry, so, I manually tried adding AllowUsers temipuser where temipuser is the username I created. Post making this change from another PuTTY Console I again tried entering this username but it is again the same. I am totally clueless why is this happening.

Another thing is, if I add any user, say just temipuser, to the AllowUsers entry in the sshd_config file, will the root user still have access or will it not get access? I don't want to screw the things here. I understand AllowUsers lets only the specified users and denies others.

share|improve this question
1  
/var/log/auth.log should use some useful information. Can you add anything you find to your question? –  Flup Mar 14 '13 at 13:21
    
Agreed. Also adjust /etc/ssh/sshd_config to set LogLevel to Debug while you try logging in to get as much information as possible. –  Shadur Mar 14 '13 at 14:16
    
Some Unix stuff chokes on usernames longer than 8 characters, your temipuser is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand if sshd reads its configuration each time, you might have to restart it (or force it to reread configuration) after changes. –  vonbrand Mar 14 '13 at 17:44
    
Are you able to ssh locally? I.e. what happens if you log in as root and then run ssh temipuser@localhost and enter the user's password when prompted? –  depquid Mar 16 '13 at 20:12
    
When i run ssh temipuser@<ip_of_server>, the same happens, it accepts username but hangs when i give password. –  Ankit Vashistha Mar 17 '13 at 8:07
show 4 more comments

4 Answers 4

look for any relevant entries under /var/log/secure or /var/log/auth.log. Also, make sure that you don't have custom rules added under /etc/security/access.conf which might access to the server for that user.

Those logs will contain information about failed logins and may indicate clearly what went wrong.

The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask) or (user/group, tty) combinations for which a login will be either accepted or refused.

share|improve this answer
add comment

Next to adding the user on the Linux machine, you'll have to generate a key (protocol type 2, preferably RSA) for that user as well. You can find instructions for that using Putty's key generator here.

Select all of the text in the ‘Public key for pasting into authorized_keys file’ box in putty's key generator, paste it into a text editor and save it under the name authorized_keys.

In the home directory of the new user on the Linux machine, create a .ssh directory if it doesn't exist. This directory should be owned by the user, and only that user should have access to it (chmod 700 .ssh) Copy the authorized_keys file to this directory. You should change the permissions of that file with chmod 0600, and change ownership to the user.

Now the user should be able to log in.

share|improve this answer
    
You do not need a key in order to login via SSH. Password login is enabled by default and if the OP had disabled it, he/she would probably remember –  Stefano Sanfilippo May 8 '13 at 23:14
add comment

To me, your problem could be be related to a permission issue, since SSH asks you for a login (so it is not a port problem), and a password (so PasswordAuthentication is set to yes, which is the default anyway).

Indeed, the way sshd works by default is that it attempts reading public SSH keys before asking for a password, and if your ~/.ssh/authorized_keys has the wrong permissions, well, the manual says that sshd will not allow you to login (see below).

With no other information about your sshd configuration (is AuthorizedKeysFile still commented; do you actually use SSH keys; etc.), my guess was made by reading the sshd manual:

 ~/.ssh/authorized_keys
        Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.
        The format of this file is described above.  The content of the file is not highly
        sensitive, but the recommended permissions are read/write for the user, and not
        accessible by others.

        If this file, the ~/.ssh directory, or the user's home directory are writable by
        other users, then the file could be modified or replaced by unauthorized users.  In
        this case, sshd will not allow it to be used unless the StrictModes option has been
        set to “no”.

So. Can you ls -l ~/.ssh/autorized_keys and double-check that only the user can read that file?

To make sure nobody but the user can read this directory, use this: chmod -v a-w,u+w ~/.ssh/authorized_keys. Option -v is for chmod to inform you of the changes it made (if any), a-w,u+w is to remove the write permissions for all, and then give the user write permissions back.

share|improve this answer
add comment

Did you test adduser temipuser instead of useradd temipuser ???

linux manual for sshd_conf said:

AllowUsers

    This keyword can be followed by a list of user name patterns, separated by 
spaces. If specified, login is allowed only for user names that match one of the 
patterns. Only user names are valid; a numerical user ID is not recognized. **By 
default, login is allowed for all users.** If the pattern takes the form USER@HOST 
then USER and HOST are separately checked, restricting logins to particular users 
from particular hosts. The allow/deny directives are processed in the following 
order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

So you don't have to add AllowUsers and if you add this option I don't think it prevent from remote root login if you enabled PermitRootLogin

share|improve this answer
add comment

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.