There are different methods of locking a user account in Linux. Each method is explained below.
Editing the /etc/passwd file by hand
This is the crudest form of disabling a user account in Linux.
Open a terminal and run the following command.
# vipw
This command will open the /etc/passwd file in your default editor which is usually Vi if you haven't explicitly set the EDITOR variable.
My /etc/passwd file is as shown below (truncated for brevity).
#FILE: /etc/passwd
...
ravi:x:500:500:Ravi Kumar:/home/ravi:/bin/bash
...
To disable a user's account - for example user 'ravi' - replace shell '/bin/bash' with '/sbin/nologin'.
#FILE: /etc/passwd
...
ravi:x:500:500:Ravi Kumar:/home/ravi:/bin/nologin
...
Now save and close the file.
Alternately, you can also enter a '!' (bang) or '*' (asterisk) just before the 'x' in the second field as shown below.
#FILE: /etc/passwd
...
ravi:*x:500:500:Ravi Kumar:/home/ravi:/bin/bash
...
Save and exit the file.
A disabled user can still login through the network using SSH which is the vulnerability of the above method.
Use chage command
The chage command changes the number of days between password changes and the date of the last password change. This information is used by the system to determine when a user must change his/her password.
The trick to disabling a user account in Linux using chage is to set the expiry of the user account to a date previous to the current one.
So for example, if today's date is October 13 2005, you can lock a user account by setting the expiry date to October 12 2005 or earlier.
# chage -E 2005-10-01 ravi
... where the date is in YYYY-MM-DD format.
You can re-enable the user's account by running the same command but changing the date to a value more recent than the current date.
Use the passwd command
This is by far the easiest way of locking or disabling a user account in Linux. To lock a user account, open a terminal and enter the following command.
# passwd -l <username>
Continuing with our previous example to lock out the user 'ravi', do the following as root / superuser.
# passwd -l ravi
And to unlock the account,
# passwd -u ravi
Check the logs for failed logins
All failed logins will be audited and logged to the file /var/log/faillog. To see who all have unsuccessfully tried to login to their account, try the following:
# faillog -a
The above command will read the /var/log/faillog file for any failed login attempts by users. It contains a history of all failed login details. This file is used when you use PAM (Pluggable Authentication Modules) for enforcing password policies.
You can change the default password policies by editing the file '/etc/login.defs'. But any changes will be applicable to only to those user accounts created after the modification of the file.
10 comments:
Editing the /etc/passwd file probably isn't the best idea.
Much easier to 'usermod -s /bin/nologin {user}'.
Not really. If you know what you are doing, editing the /etc/passwd file is the quick way of disabling the account. If you want additional security then you use command 'vipw' which opens the file in the vi editor.
usermod is only a script which does the same thing for you.
>usermod is only a script which does the same thing for you.
Who told you usermod is script? It is a ELF 32-bit LSB executable file. If you don't know then before writing up at least check on your own system or google.com/linux :P
and yes editing /etc/passwd is not a good idea at all.. that is why commands are introduced. Even if you know what you are doing ... something may go wrong why to take risk. It is ok to do things on your home/desktop computer. But no one will take a such risk on Production server.
Regards,
Steve
Oops...
My mistake. 'usermod', 'useradd' and 'userdel' happens to be executable files and not scripts.
Thanks Steve for pointing this out to me...
> "It is ok to do things on your home/desktop computer. But no one will take a such risk on Production server."
You are right there steve, on a production server you have to take additional safeguards, but then the posts on my blog are hardly targeted at battle worn system administrators.
It gives new insights on how to accomplish a task in linux which I hope will be useful to the linux enthusiast in general. But above all, it is a place where I file my notes so I can use it as a reference in the future.
Why is "passwd -l" listed as the fourth and last alternative, when it is the typical way of locking an account on *nix systems?
Yes, at this point in time "passwd -l" may only be doing simple edits to the passwd file, but in the future, or when using a different authentication method it could be doing something much more complex.
In those cases editing the passwd file using the methods 1-2 described above will break the system.
It's worth noting that sometimes editing the file by hand is more safe, such as when you're unfamiliar with the command being executed.
For instance, usermod with a -g vs a -G can be disastrous.
Another example is the inconsistency of flags and flag capitalization. The following two commands do the same thing: `usermod -L username` and `passwd -l username`.
Sometimes when you want to get something done quickly and you trust your vim skills more than your tool knowledge, it's better to use vipw. Clearly that's why the tool exists.
I manually edit passwd and shadow with vi/vipw (-s) all the time on production systems. Never had an issue with it. Of course, I make a backup just before I do the edit :-) makes adding multiple acounts much faster...cheers
I have one question. How can see the expiration date of one user account from the command prompt, or using any file?
Hi
You can use the command
chage -l username
to check the expiry date of a user.
\
Akhtar Bhat
Similar to chage you can use
chsh -s /sbin/nologin username
to change a users shell.
As an aside I've found that if you use 'password -l username' to lock and account you can't ssh into the box using the password but you can if you've got a public key setup. Can't ssh check to see if the accounts been locked? Isn't there a method that will disable an account for everything??!
The best method I've thought of so far is to use an AllowGroup for ssh access so users are denied by default and to create a 'disable user' script that will remove them from the sshusers group.
Post a Comment