Sie sind hier: Home » Dokumentation » Host-based authentication using OpenSSH

Host-based authentication using OpenSSH

Using host-based authentication, any user on a trusted host can log into another host (with the same username) 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. (Note that per-user ssh public keys can achieve similar effects; but maintaining the per-user keys could be an unwanted administrative overhead)

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. user1@trusted.example.com shall be able to login on user1@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. Your ssh installation should have a ssh-keysign helper with set-uid bit, for example in /usr/lib/openssh/ssh-keysign:
    # ls -l /usr/lib/openssh/ssh-keysign
    -rwsr-xr-x 1 root root 212128 Dec 27 12:30 /usr/lib/openssh/ssh-keysign
    
  2. Enable the usage of the ssh-keysign helper in /etc/ssh/ssh_config (has to be the global client config!)
    Host *
        EnableSSHKeySign yes
    
  3. 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.
  4. Host-based authentication has to be enabled in the client. Add the following section to /etc/ssh/ssh_config (or to your per-user config ~/.ssh/config, can be restricted to some hosts or even given on command line ssh -oHostbasedAuthentication=yes untrusted.example.com):
    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.