Trusted-Host Access Control

A limited type of per-account configuration is possible if you use trusted-host authentication rather than public-key authentication. Specifically, you can permit SSH access to your account based on the client's remote username and hostname via the system files /etc/shosts.equiv and /etc/hosts.equiv, and personal files ~/.rhosts and ~/.shosts. A line like:

+client.example.com jones

permits trusted-host SSH access by the user jones@client.example.com. Since we've already covered the details of these four files, we won't repeat the information in this chapter. [Section 3.4.2.3]
Per-account configuration with trusted-host authentication is similar to using the from option of authorized_keys with public keys. Both may restrict SSH connections from particular hosts. The differences are shown in this table.

Feature	Trusted-Host	Public-Key from
Authenticate by hostname	Yes	Yes
Authenticate by IP address	Yes	Yes
Authenticate by remote username	Yes	No
Wildcards in hostnames and IP	No	Yes
Passphrase required for logins	No	Yes
Use other public-key features	No	Yes
Security	Less	More

To use trusted-host authentication for access control, all the following conditions must be true:

• ●  Trusted-host authentication is enabled in the server, both at compile time and in the serverwide configuration file.
  
• ●  Your desired client hosts aren't specifically excluded by serverwide configuration, e. g., by AllowHosts and DenyHosts.
  
• ●  For SSH1, ssh1 is installed setuid root.
  Despite its capabilities, trusted-host authentication is more complex than one might expect. For example, if your carefully crafted .shosts file denies access to sandy@trusted.example. com:
  

  # ~/.shosts
  -trusted.example.com sandy
  

  but your .rhosts file inadvertently permits access: # ~/.rhosts
  

  +trusted.example.com
  

  then sandy will have SSH access to your account. Worse, even if you don't have a ~/.rhosts file, the system files /etc/hosts.equiv and /etc/shosts.equiv can still punch a trusted-host security hole into your account against your wishes. Unfortunately, using per-account configuration, there's no way to prevent this problem. Only compile-time or serverwide configuration can disable trusted-host authentication.
  Because of these issues and other serious, inherent weaknesses, we recommend against using the weak form of trusted-host authentication, Rhosts authentication, as a form of per- account configuration. (By default it is disabled, and we approve.) If you require the features of trusted-host authentication, we recommend the stronger form, called RhostsRSAuthentication (SSH1, OpenSSH) or hostbased (SSH2), which adds cryptographic verification of host keys. [Section 3.4.2.3]
  

Book: SSH, The Secure Shell: The Definitive Guide Section: Chapter 8. Per-Account Server Configuration
8.4 The User rc File
The shell script /etc/sshrc is invoked by the SSH server for each incoming SSH connection. Section 5.6.4 You may define a similar script in your account, ~/.ssh/rc (SSH1, OpenSSH)
or ~/.ssh2/rc (SSH2), to be invoked for every SSH connection to your account. If this file exists, /etc/sshrc isn't run.
The SSH rc file is much like a shell startup file (e.g., ~/.profile or ~/.cshrc), but it executes only when your account is accessed by SSH. It is run for both interactive logins and remote commands. Place any commands in this script that you would like executed when your account is accessed by SSH, rather than an ordinary login. For example, you can run and load your ssh-agent in this file: [Section 6.3.3]

# ~/.ssh/rc, assuming your login shell is the C shell
if ( ! $?SSH_AUTH_SOCK  ) then

  eval `ssh-agent`
  /usr/bin/tty | grep 'not a tty' > /dev/null
  if ( ! $status ) then

    ssh-add
  endif

endif
Like /etc/sshrc, your personal rc file is executed just before the shell or remote command requested by the incoming connection. Unlike /etc/sshrc, which is always processed by the Bourne shell ( /bin/sh), your rc file is processed by your account's normal login shell.

Book: SSH, The Secure Shell: The Definitive Guide Section: Chapter 8. Per-Account Server Configuration
8.5 Summary
Per-account configuration lets you instruct the SSH server to treat your account differently. Using public-key authentication, you can permit or restrict connections based on a client's key, hostname, or IP address. With forced commands, you can limit the set of programs that a client may run in your account. You can also disable unwanted features of SSH, such as port forwarding, agent forwarding, and tty allocation.
Using trusted-host authentication, you can permit or restrict particular hosts or remote users from accessing your account. This uses the files ~/.shosts or (less optimally) ~/.rhosts. However, the mechanism is less secure and less flexible than public-key authentication.