When a login occurs, the SSH server can take special actions. Here, we discuss:
Printing welcome messages for the user
Setting environment variables
Taking arbitrary actions with initialization scripts
sshd can display custom messages
for the user before and after authentication. Before authentication,
the SSH server can optionally display the contents of any file you
select with the Banner keyword
(OpenSSH) or BannerMessageFile
keyword (Tectia):
# OpenSSH
Banner /usr/local/etc/warning.txt
# Tectia
BannerMessageFile /usr/local/etc/warning.txtBy default, OpenSSH displays no banner message, whereas Tectia displays the contents of /etc/ssh2/ssh_banner_message if the file exists.[76] The banner message is often used for legal statements that forbid unauthorized access. Since the file is sent before authentication, be careful that it doesn't reveal sensitive information.
After authentication, both OpenSSH's and Tectia's
sshd optionally prints the standard Unix "message
of the day" file ( /etc/motd ).
This output may be turned on and off with the PrintMotd keyword with the value yes (the default) or no:
PrintMotd no
Since most Unix shells print /etc/motd on login, this SSH feature is often redundant and turned off.
For Tectia, 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:
# Tectia
CheckMail yesIn OpenSSH, the last login time is also printed if the PrintLastLog keyword has the value of
yes (the default), or the message
is skipped if the value is no:
# OpenSSH
PrintLastLog yesTectia has no separate keyword to control printing the last login time—it's always printed, if available.
The SSH server also obeys the Unix hushlogin convention, which allows each user to control whether these welcome messages are printed. If the file ~/.hushlogin exists, then the message of the day, the mail notification message (for Tectia), and the last login time are all omitted.
As we'll see later, SSH clients have several ways to set
environment variables in the server before the login shell is
invoked,[77] such as the environment file [7.1.3], the SendEnv (OpenSSH) or SetRemoteEnv (Tectia) configuration keywords
[7.4.4.3], and the
environment option in the authorized_keys (OpenSSH) or authorization (Tectia) file [8.2.5]. However, these
changes happen only with the server's permission; otherwise, SSH
clients could circumvent server security policies.
The OpenSSH server grants or denies permission for clients to
modify the environment in this manner, using the PermitUserEnvironment and AcceptEnv keywords. PermitUserEnvironment controls whether the
server pays attention to the user's ~/.ssh/environment file and authorized_keys files, with a value of
yes or no (the default):
# OpenSSH
PermitUserEnvironment yesAcceptEnv controls how the
server accepts or rejects environment variables that are sent from the
SSH client according to the SendEnv
(OpenSSH) or SetRemoteEnv (Tectia)
keywords. Normally the SSH server pays no attention to such
environment variables, but you can use the AcceptEnv keyword to allow specific
variables to be copied, with their values, into SSH sessions on the
server machine.
The AcceptEnv keyword lists
the environment variables that are accepted, either separated by
whitespace or specified by multiple keywords. Wildcard characters
* and ? will match classes of environment
variables.
# OpenSSH
AcceptEnv LANG LC_*
AcceptEnv PATH TERM TZLikewise, the Tectia SSH server permits or denies permission for
clients to modify the environment prior to login. Its SettableEnvironmentVars keyword lists
environment variables that can be set by any of the methods, separated
by commas (and optional whitespace), or specified by multiple
keywords. The environment variables are matched against patterns.
[11.6.1]
# Tectia
SettableEnvironmentVars LANG,LC_(ALL|COLLATE|CTYPE|MONETARY|NUMERIC|TIME)
SettableEnvironmentVars PATH, TERM, TZThe SettableEnvironmentVars
keyword applies only to user-configurable environment variables. Files
like /etc/environment controlled
by the server administrator are not affected.
In all these cases, users are still free to set any environment variables after their login shells are invoked. The restrictions apply only to the mechanisms for initializing the environment of the login shell.
When a user logs in, her Unix shell runs one or more initialization scripts , such as /etc/profile. In addition, sshd runs the script /etc/ssh/sshrc (OpenSSH) or /etc/ssh2/sshrc (Tectia) 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, etc.
The /etc/ssh/sshrc or /etc/ssh2/sshrc script is always processed by the Bourne shell ( /bin/sh), rather than the user's shell, so 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 but after environment variables are initialized. The script runs in a separate shell, which exits after the script finishes, so it cannot initialize environment variables for the session. The script 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/ssh/sshrc, not /bin/sh -c /etc/ssh/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/ssh/sshrc or /etc/ssh2/sshrc operates machinewide: it is run for every incoming SSH connection. For more fine-grained control, users may create the script ~/.ssh/rc (OpenSSH) or ~/.ssh2/rc (Tectia) to be run instead of the machinewide script /etc/ssh/sshrc or /etc/ssh2/sshrc, respectively. [8.4] The machinewide script isn't executed if the user-specific script exists in the target account, but a user script can run the machinewide script directly. OpenSSH always runs ~/.ssh/rc using the Bourne shell (like /etc/ssh/sshrc), but Tectia runs ~/.ssh2/rc using each user's shell (in contrast to /etc/ssh2/sshrc). OpenSSH ignores user scripts if a subsystem is used, but Tectia does not. [5.8]
Note that SSH rc files interact with X authentication. [9.4.5.2]