|HP-UX Reference > P
HP-UX 11i Version 3: February 2007
passwd — change login password and associated attributes
passwd -r files [-F file] [name]
passwd -r files [-e [shell]] [-gh] [name]
passwd -r files -s [-a]
passwd -r files -s [name]
passwd -r files [-d|-l] [-f] [-n min] [-w warn] [-x max] name
passwd -r nis [-e [shell]] [-gh] [name]
passwd -r dce [-e [shell]] [-gh] [name]
The passwd command modifies the password as well as the attributes associated with the login name. If name is omitted, it defaults to the invoking user's login name, which is determined using getuid. See getuid(2).
Ordinary users can only change passwords corresponding to their login name. If an old password has been established, it is requested from the user. If valid, a new password is obtained. Once the new password is entered, it is determined if the old password has "aged" sufficiently. If password aging is not sufficient, the new password is rejected and passwd terminates. See passwd(4).
If password aging and construction requirements are met, the password is re-entered to ensure consistency. If the new copy differs, passwd repeats the new password prompting cycle, at most twice.
A superuser, whose effective user ID is zero, (see id(1) and su(1)), is allowed to change any password and is not forced to comply with password aging. On a trusted system, superusers are prompted for old passwords. On standard systems, superusers are not forced to comply with password construction requirements. Refer also to the Password Construction Requirements section of this manpage. Null passwords can be created by entering a carriage return in response to the prompt for a new password.
For the files (local system) repository, if no /etc/shadow file exists, then the encrypted password is stored in the password field of /etc/passwd. If the /etc/shadow file exists, then the encrypted password is stored there, and an 'x' is added to the password field of /etc/passwd.
The DCE repository (-r dce) is only available if Integrated Login has been configured. See auth.adm(1M). If Integrated Login has been configured, other considerations apply. A user with appropriate DCE privileges is capable of modifying a user's password, shell, gecos or home directory and this is not dependent upon superuser privileges.
If the repository is not specified, that is, passwd [name], the password is changed in all existing repositories configured in /etc/nsswitch.conf. If password options are used, and no repository is specified, the default repository is files.
The following options are recognized:
Privileged User Options
A superuser can modify characteristics associated with the user name using the following options:
The min and max arguments are each represented in units of days. These arguments will be rounded up to the nearest week on a standard HP-UX system. If the system is then converted to a trusted system, the number of days will be based on those weeks. If only one of the two arguments is supplied, and the other argument does not exist, then the number of days is set to zero.
The following description applies to all repositories except nis, which does not support password aging.
The system requires a minimum time to elapse before a password can be changed. This prevents reuse of an old password within too brief a period of time. System warnings are displayed as the expiration time approaches.
A password is no longer usable after a time period known as the password lifetime. After the lifetime passes, the account is locked until it is re-enabled by a system administrator. Once unlocked, the user is forced to change the password before using the account.
The -n min and -x max arguments are each represented in units of days. These arguments are rounded up to the nearest week on a standard system. If only one of the two arguments is supplied and the other argument does not exist, then the number of days is set to zero.
Default values may be set in the /etc/default/security file for the -n min, -x max, and -w warn options. See security(4). The attributes to select password aging defaults are:
Password Construction Requirements
Passwords must be constructed to meet the following requirements:
The /etc/nsswitch.conf file specifies the repositories for which the password must be modified. The following configurations are supported:
Smart Card Login
If the user account is configured to use a Smart Card, the user password is stored in the card. This password has characteristics identical to a normal password stored on the system.
The Smart Card must be inserted into the Smart Card reader. The user is prompted for a PIN instead of a password during authentication.
The password is retrieved automatically from the Smart Card when a valid PIN is entered. Therefore, it is not necessary to know the password, only the PIN.
If the system retrieves a valid old password from the card, a new password is requested (twice). If the new password meets all requirements, the system automatically overwrites the old password stored on the card with the new password.
Therefore, the new dialog resembles:
Enter PIN: New password: Re-enter new password:
A Smart Card account can be shared among users. If one user modifies the password, other users must use the scsync command to write the new password onto their cards.
The scpin command is used to change the Smart Card PIN.
This section applies only to trusted systems. It describes additional capabilities and restrictions.
When passwd is invoked on a trusted system, the existing password is requested (if one is present). This initiates the password solicitation dialog which depends upon the type of password generation (format policy) that has been enabled on the account doing the passwd command. There are four possible options for password generation:
Passwords can be greater than eight characters, but it is recommended that they be less than 40 characters. System warnings are displayed if passwords lengths are either too long or short. The system administrator can specify a maximum password length guideline for the system generated options (random syllables, random characters, and random letters). The actual maximum password length depends upon several parameters in the authentication database and in the algorithm.
The system requires a minimum time to elapse before a password can be changed. This prevents reuse of an old password within an undesirable period of time.
A password expires after a period of time known as the expiration time. System warnings are displayed as expiration time approaches.
A password dies after a time period known as the password lifetime. After the lifetime passes, the account is locked until it is re-enabled by a system administrator. Once unlocked, the user is forced to change the password before account use.
The system administrator can enable accounts without passwords. If a user account is allowed to function without a password, the user can choose a null password by typing a carriage-return when prompted for a new password.
The system administrator can enable the password history feature to discourage users from reusing previously used passwords. Refer to the security(4) manual page for detailed information on configurable attributes that affect the behavior of this command. The attribute for password history is:
Change the password expiration date of user to 42 days in the files repository:
passwd -r files -x 42 user
Force user2 to establish a new password on the next login which will expire in 70 days and prohibit the user from changing the password until 7 days have transpired:
passwd -r files -f -x 70 -n 7 user2
Pluggable Authentication Modules (PAM)
PAM is an Open Group standard for user authentication, password modification, and account validation. In particular, pam_chauthtok() is invoked to perform all functions related to passwd. This includes establishing and changing a password, using passwd options, and displaying error messages.
Avoid password characters which have special meaning to the tty driver, such as # (erase) and @ (kill). You may not be able to login with these characters.
Multiple superusers are allowed, but are strongly discouraged. That is because the system often stores user ID rather than user name. Having unique IDs for all users will guarantee a consistent mapping between user name and user ID.
HP-UX 11i Version 3 is the last release to support trusted systems functionality.
HP-UX System Administrator's Guide