Although using Public Key Infrastructure (PKI) with SSH is strongly recommended over password authentication, basic UNIX password authentication (using username and password for authentication) is still widely prevalent. If you are one of those users still using password authentication, then this tutorial could provide you with essential information to enable you manage your passwords and prepare to switch to PKI or other more secure methods of authentication. The examples in this tutorial are based on Fedora 11 Linux, Ubuntu 9.04 Linux and Solaris 10 (x86) and will apply to all these UNIX distributions unless otherwise mentioned. The examples for Fedora 11 will most probably apply to Red Hat Enterprise Linux (RHEL) as Fedora is a spin-off of the terminated Red Hat Linux Desktop and shares code with RHEL.
When and where are passwords created?
Passwords for users are created when a user is created. Users are typically created with the useradd command. An example user creation is given below:
useradd -d /home/asg -m -s /bin/bash asg
The above command creates a user called asg with home directory /home/asg and the bash shell and will work on
Upon creation of a user, a blank password is created, locked and assigned to that user and all password details for that user are stored in the /etc/shadow file as shown below.
# Fedora 11
asg:!!:14479:0:99999:7:::
# Ubuntu 9.04
asg:!:14479:0:99999:7:::
# Solaris 10
asg:*LK*:::::::
Note the differences in default password creation among the three UNIX distributions:
(1) Notation used to denote password locking. In Fedora 11, it’s "!!", in Ubuntu 9.04, it’s "!" and in Solaris 10, it’s "*LK*".
(2) In both Fedora 11 and Ubuntu 9.04, days that denote when the password was last changed (14479 days since 01/01/1970), before which a password may be changed (0 days), after which a password must be changed (99999 days) and the warning before a password expires (7 days) are assigned (defaults assigned in /etc/login.defs and /etc/default/useradd) whereas in Solaris 10, these values are not defined.
Refer to the shadow manual (man /etc/shadow) to understand the fields associated with a password definition (a colon separated line) for a user in the /etc/shadow file.
How do you set passwords?
Passwords are set using the “passwd” command as shown below:
# For non-root users (e.g. asg)
passwd
# For root user (e.g. set the password for the asg user)
passwd asg
Note: Non-root users can set only their own passwords (unless given elevated privileges) whereas the root user can set any user’s password.
When a password is set, it will be encrypted and stored in the /etc/shadow file as in the example shown below (single line):
asg:$6$TcNyv6EyQchM.:14479:0:99999:7:::
How do you lock passwords?
By default, as seen above, passwords are locked during user creation. If you need to lock a password any time after it has been unlocked, then the following command must be run as the "root" user:
# As root user, lock the password for the asg user
passwd -l asg
When a password is locked, the corresponding user’s account cannot be used and you cannot login directly as the user or even switch user using su.
Note: In Fedora 11 and Ubuntu 9.04, a user whose password has been locked will still have its cron jobs running normally, but in Solaris 10, such a user’s cron jobs will no longer execute.
How do you unlock passwords?
You can unlock a user’s password (as root user) in one of two ways as shown in the example below:
# Option 1: Simply set the asg user's password
passwd asg
# Option 2: Unlock the asg user's password
passwd -u asg
How do you delete passwords?
You can delete a user’s password (as root user) by using the passwd command as shown in the example below:
# Delete the asg user's password
passwd -d asg
How do you manage password expiry?
Just like perishables, passwords too can have lifetimes and expire. By default, when users are created, password expiry is not set, thereby allowing a password to be used forever without ever being changed. Well, password authentication is not a very secure authentication mechanism and so apart from setting difficult-to-guess passwords, it is important to change passwords often to reduce the risk of security being compromised. Password expiry may be set (as root user) as shown in the examples below:
# Option 1 : Using the passwd utility, set expiry of the asg user's password to 30 days from now
passwd -x 30 asg
# Option 2 (Fedora 11 and Ubuntu 9.04): Using the chage utility, set expiry of the asg user's password to 30 days from now
chage -M 30 asg
Password expiry may be unset (as root user) as shown in the examples below:
# Option 1(a) : Using the passwd utility, turn off expiry for the asg user.
passwd -x -1 asg
# Option 1(b) : Using the passwd utility, turn off expiry for the asg user.
passwd -x 99999 asg
# Option 2(a) (Fedora 11 and Ubuntu 9.04): Using the chage utility, turn off expiry for the asg user.
chage -M -1 asg
# Option 2(b) (Fedora 11 and Ubuntu 9.04): Using the chage utility, turn off expiry for the asg user.
chage -M 99999 asg
Note:If using password authentication, I recommend that password expiry is always turned off or disabled for system/shared user accounts to prevent inefficiencies caused by dependencies on password tracking.
What is the difference between deleted, locked and expired passwords?
Some people refer to deleted passwords as disabled passwords, but I will refrain from using the term "disabled" as it only adds ambiguity. Refer to the table below to understand the differences and similarities between deleted and locked passwords.
| Feature |
Ubuntu 9.04 |
Fedora 11 |
Solaris 10 |
Login directly with user account (username/password)
NOTE: If your password has expired, you can login directly, provided you remember your old password when prompted to set a new password as soon as you login. |
No (deleted)
No (locked)
Yes (expired) |
No (deleted)
No (locked)
Yes (expired) |
No (deleted)
No (locked)
Yes (expired) |
| Switch user (su) to user account |
No (deleted)
No (locked)
No (expired) |
Yes (deleted)
No (locked)
No (expired) |
Yes (deleted)
No (locked)
No (expired) |
| Cron jobs run normally (assuming password hasn’t expired) |
Yes (deleted)
Yes (locked)
No (expired) |
Yes (deleted)
Yes (locked)
No (expired)
|
Yes (deleted)
No (locked)
No (expired) |
How do you disable password authentication for only certain users?
Password authentication is still widely used on UNIX Production systems. And some systems even still use the telnet daemon to accept connections. The telnet protocol is insecure as the password is transmitted in plain text and if you’re using telnet on UNIX Production systems, discontinue its use and switch to the SSH daemon at the earliest. If you wish to disable password authentication for all users, then setting the directive "PasswordAuthentication no" in the sshd_config file and restarting the sshd daemon will ensure no user can use password authentication. If on the other hand, like me, you are not a System Administrator and wish to disable password authentication only for specific users (your team perhaps), then you may do so as follows (Fedora 11, Ubuntu 9.04 & most Linux distributions):
(1) Ensure each user creates a public-private key pair and configures his/her public key in the appropriate home directory, in order to use PKI/SSH to login.
(2) Turn off expiry for user passwords in order to prevent any impact on cron jobs.
(3) Lock the users’ passwords in order to prevent password authentication.
(4) For shared or system users, ensure elevated privileges are provided to normal users using softwares like sudo or Power Broker. If using sudo, the users may have to remember their passwords even though they’re using PKI, in order to use the sudo command (not mandatory, depends on sudo setup).
I know the above steps seem a weird way of configuration (use passwords and then prevent password authentication), but I haven’t found any other direct way of disabling password authentication for certain users. Using Pluggable Authentication Modules (PAM), this may be possible, but this tutorial is aimed at users currently using basic password authentication without services like PAM, kerberos, etc.
Note: I do not recommend the above 4-step procedure for Solaris 10 (& probably earlier versions) as step 3 effectively ensures that the users’ cron jobs stop working.
References:
(1) UNIX manuals (man passwd, man chage, man shadow, man sshd): As always, read the manual!
(2) Steve Friedl’s Secure Linux/UNIX access with PuTTY and OpenSSH: An excellent, lucid tutorial to help you get started with using PKI and SSH.
(3) Werner Puschitz’s Securing and Hardening Red Hat Linux Production Systems: An excellent guide on securing Production RHEL systems (also covers PAM).
VN:F [1.6.5_908]
