Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

is the only method to prevent a user from logging into the server setting the users shell to /dev/null?

share|improve this question

6 Answers 6

You can set their shell to /bin/false or any other non-interactive binary :)

My assumption, as it is not stated, is that your are talking about a GNU\Linux system here. You can use passwd to lock their account:

~#passwd -l username

This modifies the encrypted password field in /etc/shadow to an "invalid" value.

share|improve this answer
1  
Agreed. Use the built-in mechanism. But also be aware that there are devious ways of still doing things depending on how your system is configured. Watch out for .forward files and the like. –  Matt Simmons Dec 12 '09 at 13:12

Agree with ironchef regarding that configuring your sshd with AllowUsers or AllowGroups alternatively DenyUsers or DenyGroups might be a good solution, depending on what you are specifically trying to accomplish.

Regarding the option of setting a denying shell. If you have a /sbin/nologin available that might be preferable to /dev/null or /bin/false. Using /sbin/nologin will basicly have the same effect (non-zero exit), but with the extra bonus of the user getting a short message about the login being disabled.

Since you seem to want to keep the account around I assume you might be using them for something else? Depending on what that is, the locking of accounts may or may not be a good idea.

As already stated, please let people know what problem you are trying to solve, etc. Usually you can get a lot better advice that way.

share|improve this answer

Another alternative to using passwd -l would be to use passwd -d and delete the user's password.

share|improve this answer
    
As dangerous as this sounds at first glance, it worked for me when I tested it. I was worried that it would allow a user to login with literally no password, but it doesn't. After investigating, I found that the PAM configuration line "password requisite pam_unix.so nullok obscure md5" treats any passwordless account as being locked, and it won't auth, even over something like telnet (which I tried). Good answer. +1 –  Matt Simmons Dec 12 '09 at 13:22
    
that's why it says "delete", and not "remove" :) –  warren Dec 13 '09 at 0:27

I would aks what you're trying to do to get a better idea. For sake of expediency, if you only allow ssh as the access method, you can limit who can login by using AllowUser (only users explicitly in AllowUser will be allowed by sshd to login).

share|improve this answer

You should set it to /bin/false instead of /dev/null.

usermod -L myaccountname disables the password for that user

If the user have a SSH public key, you might wanna disable it too : rm /home/clem/.ssh/authorized_keys* (use mv if you want to restore it later) You could also explicitely restrict allowed users with sshd's AllowUser directive (in /etc/ssh/sshd.conf).

share|improve this answer

Pam_access provides a good method to restrict access to a subset of users. Check out "man pam_access" for more details. The pam configuration will have to be modified. Most of the configuration happens in /etc/security/access.conf. This module is pretty flexibly in restricting access to just particular users, or users who belong in particular groups. The restrictions can be applied across all services, or just to particular services, depending on where pam_access is included within pam.

I've actually gone as far as running two separate access.conf like files, using one for shell access, and one for ftp/rcp access. Pam_access allows us to maintain separate policies for various protocols. The downfall of this flexibility is the configuration is a bit more complex, which may not be needed.

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.