A limited type of per-account configuration is possible in OpenSSH if you use hostbased 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 hostbased 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. [3.6.2]
Per-account configuration with hostbased authentication is similar to using host access control in your OpenSSH authorized_keys or Tectia authorization file. [8.2.4] Both methods may restrict SSH connections from particular hosts. The differences are shown in this table:
Feature | Hostbased access | Public-key host access |
|---|---|---|
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 hostbased authentication for access control, all of the following conditions must be true:
Hostbased 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 OpenSSH, the server configuration keyword EnableSSHKeysign must be set to yes.[127]
Despite its capabilities, hostbased 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 sandybut your .rhosts file inadvertently permits access:
# ~/.rhosts
+trusted.example.comthen 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 hostbased 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 hostbased authentication.
Because of these issues and other serious, inherent weaknesses, we
recommend against using the weak form of hostbased authentication,
Rhosts authentication, as a form of per-account configuration. (By
default it is disabled, and we approve.) If you require the features of
hostbased authentication, we recommend the stronger form, called
RhostsRSAAuthentication (OpenSSH) or
hostbased (Tectia), which adds cryptographic verification of host
keys.