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.txt

By 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 yes

In 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 yes

Tectia 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 yes

AcceptEnv 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 TZ

Likewise, 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, TZ

The 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]