Using host-based authentication, any user on a trusted host can log into another host on which this feature is enabled. This authentication is useful in an environment with a trusted host and several untrusted systems. Passwords no longer have to be transferred to the untrusted systems.
RequirementsIt is recommended that you use at least OpenSSH 3.4p1 on both clients and servers.
ScenarioWe have got two hosts,
untrusted.example.com. We want to perform host-based authentication from
untrusted.example.com, i.e. user on
trusted.example.comshall be able to login on
untrusted.example.comwithout supplying a password.
We assume that all SSH configuration files are stored in
Configuration on the clientOn
trusted.example.com, the following changes are required:
sshbinary (usually stored in
/usr/local/bin/ssh) has to be maded set-uid
# chown root /usr/bin/ssh
# chmod u+s /usr/bin/ssh
# ls -l /usr/bin/ssh
-rwsr-xr-x 1 root root 230216 Jul 31 08:49 /usr/bin/ssh
- Host keys for protocol version 2 are required. The files are called
.pubvariants). You can create these files using
- Host-based authentication has to be enabled in the client. Add the following section to
Configuration of the serverOn
untrusted.example.com, these changes are needed:
- Of course, host-based authentication has to be enabled in the server, by changing the
/etc/ssh/sshd_configfile and inserting the following line (or replacing an uncommented
- The public part of the the host keys of
trusted.example.comhave to be added to the
/etc/ssh/ssh_known_hostsfile. In contrast to the
authorized_keysfile you might know from user-oriented public-key authentication, this file is stored in the known hosts file format, i.e. you have to prefix each line with the host name and its IP adress (separated by a comma).
For example, if the RSA public host key on
trusted.example.comlooks like this:
ssh-rsa AA lots of characters MM= firstname.lastname@example.org
You have to add the following line to
trusted.example.com,192.0.2.1 ssh-rsa AA lots of characters MM= email@example.com
A similar line should be added for the DSA host key.
- Using the line above,
untrusted.example.comcan authenticate requests from
trusted.example.com. It is still necessary to instruct the SSH server on
untrusted.example.comto authorize host-based authentication requests coming from
trusted.example.com. For this, you need to create a file
/etc/ssh/shosts.equivwith the following line in it:
untrusted.example.com. As a consequence, you should never enable host-based authentication unless
trusted.example.comis already a trusted system (i.e. on which you completely depend), and a compromise of
untrusted.example.comis a minor annoyance compared to a break-in on this trusted host.
- The SSH client on
trusted.example.comis now set-uid
root. (See the remarks under the previous point.)
- An additional authentication method is enabled in the client on
trusted.example.com. This exposes more OpenSSH client code to attacks from malicious SSH servers.
- Similarly, on the server
untrusted.example.com, more code is exposed to attacks, too.