User Logins and Accounts (SSH, The Secure Shell: The Definitive Guide)

5.6. User Logins and Accounts

When a login occurs, the SSH server can take special actions. Here, we discuss:

Printing welcome messages for the user
Handling expired accounts or passwords
Handling empty passwords
Taking arbitrary actions with /etc/sshrc

5.6.1. Welcome Messages for the User

When users log in, sshd prints informative messages such as the " message of the day" file ( /etc/motd ) and whether the user has email. This output may be turned on and off in the configuration file. Since most Unix shells print this information on login, these SSH features are frequently redundant and turned off.

To enable or disable the message of the day, use the PrintMotd keyword with the value yes (the default) or no:

# SSH1, SSH2, OpenSSH
PrintMotd no

Incidentally, sshd obeys the Unix "hushlogin" convention. If the file ~/.hushlogin exists, /etc/motd isn't printed on login, regardless of the PrintMotd value.

A message about email (e.g., "You have mail") is printed on login if the CheckMail keyword has the value of yes (the default), or the message is skipped if the value is no:

# SSH1, SSH2, OpenSSH
CheckMail yes

5.6.2. Expired Account or Password

If a user's password or computer account is expiring soon, sshd1 can optionally print warning messages when the user logs in via SSH:

WARNING: Your password expires in 7 days
WARNING: Your account expires in 10 days

These messages are turned on and off by the keywords PasswordExpire-WarningDays and AccountExpireWarningDays, respectively:

# SSH1 only
PasswordExpireWarningDays 7
AccountExpireWarningDays 10

The value following the keyword is a number of days, and by default, both values are 14. A zero value means that the warning message is suppressed. Note that account and password expiration aren't features of SSH, but of the host operating system.[72]

[72]Account expiration requires that your operating system support /etc/shadow. Password expiration requires struct passwd to have a pw_expire field à la FreeBSD.

If a password has expired, the SSH1 server can prompt the user to change it upon login. This feature is controlled by the keyword ForcedPasswdChange, given a value of yes or no (the default). If the feature is enabled:

# SSH1 only
ForcedPasswdChange yes

the user is prompted to change a password if expired. Until this password is changed, SSH connections aren't accepted.

5.6.3. Empty Passwords

If password authentication is used, and an account has an empty password, the SSH server may refuse access to the account. This feature is controlled by the keyword PermitEmptyPasswords with a value of yes (the default) or no. If enabled:

# SSH1, SSH2, OpenSSH
PermitEmptyPasswords yes

empty passwords are permissible; otherwise not.

The SSH1 server additionally may require users with empty passwords to change them. The keyword ForcedEmptyPasswdChange controls this feature much like ForcedPasswdChange for expired passwords. The ForcedEmptyPasswdChange keyword may have a value of yes or no (the default):

# SSH1 only
ForcedEmptyPasswdChange yes

If the value is yes and the password is empty, then upon login, the user is prompted to change his or her password and can't log in until the change is made.

5.6.4. Arbitrary Actions with /etc/sshrc

When a user logs in, the normal Unix login system typically runs some shell scripts, such as /etc/profile. In addition, sshd runs the script /etc/sshrc for each SSH-based login. This feature lets the system administrator run special commands for SSH logins that don't occur for ordinary logins. For example, you can do some additional logging of SSH connections, print welcome messages for SSH users only, and set SSH-related environment variables.

In all three, SSH1, SSH2, and OpenSSH, /etc/sshrc is processed by the Bourne shell ( /bin/sh) specifically, rather than the user's shell, so that it can run reliably for all accounts regardless of their various shells. It is run for logins (e.g., ssh my-host) and remote commands (ssh my-host /bin/who), just before the user's shell or command is invoked. It runs under the target account's uid, so it can't take privileged actions. If the script exits due to an error (say, a syntax error), the SSH session continues normally.

Note that this file is run as input to the Bourne shell: sshd runs /bin/sh /etc/sshrc, not /bin/sh -c /etc/sshrc. This means that it can't be an arbitrary program; it must be a file containing Bourne-shell commands (and it doesn't need the execute mode bit set).

/etc/sshrc operates machinewide: it is run for every incoming SSH connection. For more fine-grained control, each user may create the script ~/.ssh/rc to be run instead of /etc/sshrc. [Section 8.4, "The User rc File "] /etc/sshrc isn't executed if ~/.ssh/rc exists in the target account. Note that SSH rc files interact with X authentication. [Section 9.3.5.2, "xauth and the SSH rc files"]

5.6.4.1. /etc/nologin

If the file /etc/nologin exists, sshd allows only root to log in; no other accounts are allowed access. Thus, touch /etc/login is a quick way to restrict access to the system administrator only, without having to reconfigure or shut down SSH.


5.5. Letting People in: Authentication and Access Control		5.7. Subsystems