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 noIncidentally, 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 yes5.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
[18]
expiration aren't features of SSH, but of the host operating system.
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] /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]
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.
[18]
Account expiration requires that your operating system support /etc/shadow. Password
expiration requires struct passwd to have a pw_expire field à la FreeBSD.
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] /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]
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.
[18]
Account expiration requires that your operating system support /etc/shadow. Password
expiration requires struct passwd to have a pw_expire field à la FreeBSD.
Book: SSH, The Secure Shell: The Definitive Guide
Section: Chapter 5. Serverwide Configuration
5.7 Subsystems
Subsystems are a (mostly undocumented) layer of abstraction for defining and invoking remote commands in SSH2 and OpenSSH/2. Normally you invoke remote commands ad hoc by providing them on the client command line. For instance, the following line invokes the Unix backup program tar remotely to copy the /home directory to tape:
[19]
executed conveniently. These commands are defined in the server configuration file, and the syntax is slightly different between OpenSSH and SSH2. A subsystem for invoking the preceding backup command is:
To run this command on the server machine, invoke ssh with the -s option: # SSH2, OpenSSH/2
The default sshd2_config file defines one subsystem: subsystem-sftp sftp-server
5.7 Subsystems
Subsystems are a (mostly undocumented) layer of abstraction for defining and invoking remote commands in SSH2 and OpenSSH/2. Normally you invoke remote commands ad hoc by providing them on the client command line. For instance, the following line invokes the Unix backup program tar remotely to copy the /home directory to tape:
# SSH2, OpenSSH/2
$ ssh server.example.com /bin/tar c /home
Subsystems are a set of remote commands predefined on the server machine so they can be
[19]
executed conveniently. These commands are defined in the server configuration file, and the syntax is slightly different between OpenSSH and SSH2. A subsystem for invoking the preceding backup command is:
# SSH2
subsystem-backups /bin/tar c /home
# OpenSSH/2
subsystem backups /bin/tar c /home
Note that SSH2 uses a keyword of the form "subsystem-name" with one argument,
whereas OpenSSH uses the keyword "subsystem" with two arguments. This SSH2 syntax
is quite odd and unlike anything else in its configuration language; we don't know how it
ended up that way.
To run this command on the server machine, invoke ssh with the -s option: # SSH2, OpenSSH/2
$ ssh -s backups server.example.com
This command behaves identically to the previous one in which /bin/tar was invoked
explicitly.
The default sshd2_config file defines one subsystem: subsystem-sftp sftp-server
Don't remove the subsystem-sftp line from sshd2_config: it
is required for scp2 and sftp to work. Internally, both programs
run ssh2 -s sftp to perform file transfers.
Subsystems are mainly a convenience feature to predefine commands for SSH clients to
invoke easily. The additional level of abstraction can be helpful to system administrators,
who can define and advertise useful subsystems for their users. Suppose your users run the
Pine email reader to connect to your IMAP server using SSH2 to secure the connection.
[Section 11.3] Instead of telling everyone to use the command:
5.7.1 Disabling the Shell Startup File
If your remote shell is C shell or tcsh, it normally reads your remote shell startup file (. cshrc, .tcshrc) at the beginning of the session. Some commands in these startup files, particularly those that write to standard output, may interfere with the file-copy commands scp2 and sftp. In SSH2, file copying is accomplished by the sftp-server subsystem, so SSH2 disables reading of .cshrc and .tcshrc for subsystems. [Section 3.5.2.4] You can
reenable this with the keyword AllowCshrc-SourcingWithSubsystems, providing a value of yes (permit .cshrc and .tcshrc sourcing) or no (the default):
$ ssh2 server.example.com /usr/sbin/imapd
and revealing the path to the IMAP daemon, imapd, you can define a subsystem to hide the
path in case it changes in the future:
# SSH2 only
subsystem-imap /usr/sbin/imapd
Now users can run the command:
$ ssh2 -s imap server.example.com
to establish secure IMAP connections via the subsystem.
5.7.1 Disabling the Shell Startup File
If your remote shell is C shell or tcsh, it normally reads your remote shell startup file (. cshrc, .tcshrc) at the beginning of the session. Some commands in these startup files, particularly those that write to standard output, may interfere with the file-copy commands scp2 and sftp. In SSH2, file copying is accomplished by the sftp-server subsystem, so SSH2 disables reading of .cshrc and .tcshrc for subsystems. [Section 3.5.2.4] You can
reenable this with the keyword AllowCshrc-SourcingWithSubsystems, providing a value of yes (permit .cshrc and .tcshrc sourcing) or no (the default):
# SSH2 only
AllowCshrcSourcingWithSubsystems yes
SSH2 disables the sourcing of remote .cshrc and .tcshrc files by passing the -f command-
line option to the remote C shell or tcsh invocation.
[19]
Abstractly, a subsystem need not be a separate program; it can invoke a function built into the
SSH server itself (hence the name). But there are no such implementations at the moment.
Abstractly, a subsystem need not be a separate program; it can invoke a function built into the
SSH server itself (hence the name). But there are no such implementations at the moment.
