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.
EnableSSHKeysign yes HostbasedAuthentication yes
HostbasedAuthentication yes
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):
Host source destination foo bar baz other Hostname %h.example.comThis makes ssh always use FQDNs for the specified hosts. (Unfortunately there's no ssh_config pattern for hosts that means "match all hostnames with no dot".) But if your ssh version is recent enough (and you aren't looking at NFS-mounted home directories in a mixed environment of different ssh versions). An even better choice is to use the canonicalization options in OpenSSH 6.5 and later:
CanonicalizeHostname yes CanonicalDomains example.com #do not "fix" anything more than 0 dots: CanonicalizeMaxDots 0 #only if you have some wierd local hostnames you need to use now and then: CanonicalizeFallbackLocal yesThis will make all hosts automatically added to your known_hosts file FQDN names, and should simplify the configuration and eliminate hostname mistmatches as a source of errors.
source,source.example.com,192.168.10.20 ssh-rsa PublicKeyDataHere... destination,destination.example.com,192.168.10.21 ssh-rsa PublicKeyDataHere...This is probably the best and most secure choice. If you update a host and its host keys you can update your known_hosts files to match and users will never see warnings that host keys have changed, and hostbased authentication will always work in the cases where you want it to work.
This can be maintained via scripts, or by centralized control with ansible, puppet, chef, etc, or by hand for a small number of machines.
8 comments:
![]() |
|
![]() |
Send Me Email |