OpenSSH has an annoyingly misleading sshd error log message

August 28, 2017

Suppose that you are trying to get some form of SSH server authentication going that uses hostnames. This might be straightforward host-based authentication to enable root on a master machine to have access to subordinate machines, or it might be hostname-based Match statements to enable or disable some restrictions (as one other example where you can use hostnames). However, it's not working; when you try host-based authentication, for example, you get a log message on the target machine saying something like:

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

This certainly looks like a straightforward problem where the target machine can't do reverse lookups to turn 128.100.X.Y into a hostname (or perhaps it can't do forward lookups to verify that hostname, although we might expect a slightly different error there). And in fact you can get this message logged when, for example, there is no DNS PTR record for 128.100.X.Y.

But there is another important case where you will get this message, and that is this message is also logged when OpenSSH sshd is not even trying to turn IPs into hostnames. To quote straight from sshd_config(5):

Specifies whether sshd(8) should look up the remote host name, and to check that the resolved host name for the remote IP address maps back to the very same IP address.

If this option is set to no (the default) then only addresses and not host names may be used in ~/.ssh/authorized_keys from and sshd_config Match Host directives.

The name UseDNS is somewhat misleading, because as the manual page correctly describes having this off turns off all forms of looking up the remote host name, not just DNS. For example, if you have backup entries in /etc/hosts, they're not checked either.

There's a bit of history that may catch you out here, which is that the OpenSSH default for UseDNS changed in the relatively recent past. According to the OpenSSH release notes, UseDNS defaulted to yes before OpenSSH 6.8; 6.8 changed the default to no when it was released in early 2015. March 2015 might seem like a long time ago, but Ubuntu 14.04, CentOS 7 (and CentOS 6), and Debian Jessie (the current 'oldstable') are all old enough that they have a pre-6.8 version of OpenSSH. This means that if, say, you moved from Ubuntu 14.04 to Ubuntu 16.04 and you use the stock sshd_config on both systems, you've had UseDNS's value change on you such that your 16.04 systems won't accept hostname-based authentication when your 14.04 systems do.

(FreeBSD 9.3 also has a pre 6.8 OpenSSH, in case you're running a machine that old.)

I can guess how this error message came about; I suspect that when UseDNS is off, the code simply skips trying to resolve the IP and basically acts as if the IP to name resolution failed. However the net effect of not differentiating the two cases is that sshd emits a misleading error message that can lead you on a significant wild goose chase as you try to figure out why OpenSSH is failing to turn your IP addresses into names. Life would probably be a lot simpler if OpenSSH logged a separate message to the effect of 'ignoring client-sent hostname and using only IP address X because UseDNS is off'.

(There's some question about when sshd should log this message. The ideal case would be that it would get logged as an error if UseDNS was off and sshd detected that you were trying to use hostname-based authentication or matching operators. This is definitely a real error that's worth reporting, because sshd knows that you're trying to do something that can never succeed.)

Written on 28 August 2017.
« The types of attachments we see for malware-laden email
We've wound up using the spam scores from some other mail systems »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Aug 28 22:49:44 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.