Implementing ssh hostbased authentication

Why?

Most people will tell you that hostbased authentication is a bad idea, that it is not secure. So here's an invaluable lesson in the foundations of computer security:

  • Nothing is purely "secure" or purely "not secure". Security is something that must be measured against a security model, or design, or policy, that talks about what assets you are protecting and who you are protecting them from.
  • Is hostbased authentication a bad idea in many or most cases? Yes. But not always.

    One typical use case for hostbased authentication is a collection of machines deemed to live within a security perimeter. They may all share the same network disk resources. For example, machines that all share the same set of accounts, and network-mounted home directories, and lie in a private network, are a perfect case. If one machine were broken into, this is bad, but if two or three machines were broken into this is arguably no worse in terms of asset access than one machine. Therefore there's no reason to restrict users from moving freely from one machine to the next. The convenience of automatic passwordless ssh (if it is helpful to your users) may outweigh any security concerns.

    But primarily this is not about the why, but the how.

    How does it work?

    Hostbased authentication is trickier to set up than you might think and it can go astray in several places. To best be able to troubleshoot a setup, you should understand all the steps involved in completing a successful hostbased ssh authentication.

    1. A user on source.example.com runs "ssh destination".
    2. source establishes a port 22 connection to destination
    3. source checks its local known_hosts database (/etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts) for the public host key of "destination".
    4. source verifies that the data sent by destination maches the public hostkey it found locally (using pubkey encryption and data encrypted by destination to test the public key). Note: local pubkey lookup for "destination" (in a known_hosts file) must be an exact match for the host you requested in the ssh command.
    5. source tells destination it can do hostbased authentication ("HostbasedAuthentication yes" in source's ssh_config)
    6. destination tells source it can do hostbased authentication ("HostbasedAuthentication yes" in destination's sshd_config)
    7. destination looks up source's hostname from the bound IP address and makes sure it is in /etc/hosts.equiv or /etc/shosts.equiv. [Does it look it up or use the sent data?]
    8. source encrypts a bit of data (perhaps its own looked-up hostname?) using source's private key, and the command ssh-keysign (which usually needs to be setuid or setgid to something that can read the private key).
    9. source sends destination the encrypted data
    10. destnation looks up "source.example.com" (probably) in its known_hosts files (/etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts).
    11. If it finds a public key, it uses it to decrypt the encrypted data sent by source, and verifies the hosts match.
    12. If everything succeeded up to this point, hostbased authentication succeeds and you are logged in with no password.

    How do I set it up?

    Why doesn't it work?

    Proper known_hosts setup and dealing with name mismatch problems

    If your environment lets users use short hostnames (e.g. your resolver is set to automatically search your domain ("example.com") if the provided host doesn't resolve as given), then users can type "ssh destination" resulting in automatically populating the ~/.ssh/known_hosts file with an entry for "destination" even though ssh is translating this into "destination.example.com". This is fine but that entry for "destination" can't be used when you ssh the other direction and "destination" is being checked against the source ssh from "destination.example.com".

    A lot of these problems also come when users automatically populate their known_hosts files because StrictHostKeyChecking is set to "no" or "ask" (or "accept-new" if your system supports that) in NFS home-mounted environments. Relying on this mechanism to add keys can result in inconsistent shortname and FQDN entries being added. It can also create additional problems, as it is not intuitive for users that hostbased authentication will work between two hosts only if they've both been added to the known_hosts file (in appropriate forms). Relying on automated updates to known_hosts can be made to work but is not the recommended situation.

    If you're experiencing host name matching problems there are a few things you can do to solve them (starting with the likely worst choice and moving to the arguably best):


    Reader Comments (Experimental. Moderated, expect delays. Posts may be edited or ignored. I reserve the right to remove any or all comments, at any time.)

    3 comments:

    At 2021/05/27 14:57
    Chris D wrote:

    You say that, "Unfortunately there's no ssh_config pattern for hosts that means "match all hostnames with no dot". Have you considered this version?

     

    Host *.*

    Hostname %h

    Host *

    Hostname %h.example.com

    Chris

    At 2021/05/27 15:01
    wrote:

    No, I haven't tried that. It looks like it should work though. Thanks!

    At 2021/06/20 19:53
    Norm Gaywood wrote:

    This was most helpful, thank you!

    Some time ago the default in Fedora in sshd_config for UseDNS changed from Yes to No.

    I found that I had to:

    sshd_config:UseDNS yes

    Otherwise I'd get a log message like this:

    sshd[2540]: userauth_hostbased mismatch: client sends HOSTNAME, but we resolve 128.100.X.Y to 128.100.X.Y

    See:

    https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OpenSSHUseDNSErrorAnnoyance

    End Comments

    Add a comment


    Tom Fine's Home Send Me Email