Friday, July 27, 2007

Host-based authentication using OpenSSH

Taken from http://cert.uni-stuttgart.de/doc/openssh/host-based.php

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.

Requirements

It is recommended that you use at least OpenSSH 3.4p1 on both clients and servers.

Scenario

We have got two hosts, trusted.example.com and untrusted.example.com. We want to perform host-based authentication from trusted.example.com to untrusted.example.com, i.e. user on trusted.example.com shall be able to login on untrusted.example.com without supplying a password.

We assume that all SSH configuration files are stored in /etc/ssh.

Configuration on the client

On trusted.example.com, the following changes are required:
  1. The ssh binary (usually stored in /usr/bin/ssh or /usr/local/bin/ssh) has to be maded set-uid root:

    # 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
    #
  2. Host keys for protocol version 2 are required. The files are called /etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key (and the .pub variants). You can create these files using ssh-keygen.
  3. Host-based authentication has to be enabled in the client. Add the following section to /etc/ssh/ssh_config:

    Host *
    HostbasedAuthentication yes

Configuration of the server

On untrusted.example.com, these changes are needed:
  1. Of course, host-based authentication has to be enabled in the server, by changing the /etc/ssh/sshd_config file and inserting the following line (or replacing an uncommented HostbasedAuthentication directive):

    HostbasedAuthentication yes 
  2. The public part of the the host keys of trusted.example.com have to be added to the /etc/ssh/ssh_known_hosts file. In contrast to the authorized_keys file 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.com looks like this:

    ssh-rsa AA lots of characters MM= root@trusted.example.com

    You have to add the following line to /etc/ssh/ssh_known_hosts on untrusted.example.com:

    trusted.example.com,192.0.2.1 ssh-rsa AA lots of characters MM= root@trusted.example.com

    A similar line should be added for the DSA host key.

  3. Using the line above, untrusted.example.com can authenticate requests from trusted.example.com. It is still necessary to instruct the SSH server on untrusted.example.com to authorize host-based authentication requests coming from trusted.example.com. For this, you need to create a file /etc/ssh/shosts.equiv with the following line in it:

    +trusted.example.com 
After these changes, you should be able to use host-based authentication on trusted.example.com/CODE>.

Security considerations

  • If trusted.example.com is compromised, untrusted.example.com. As a consequence, you should never enable host-based authentication unless trusted.example.com is already a trusted system (i.e. on which you completely depend), and a compromise of untrusted.example.com is a minor annoyance compared to a break-in on this trusted host.
  • The SSH client on trusted.example.com is 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.