8.3. 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
[email protected]. 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, "Trusted-host authentication (Rhosts and RhostsRSA)"]
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
[email protected]:
# ~/.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, "Trusted-host authentication (Rhosts and RhostsRSA)"]
 |  |  |
| 8.2. Public Key-Based Configuration |  | 8.4. The User rc File |
