Bug#989277: openssh-client: Always sends the short hostname for HostbasedAuthentication

Package: openssh-server
Version: 1:8.4p1-5

Dear maintainers,

When doing host-based authentication, sshd tries to look up the hostname
of the IP that's connecting and compares it to a hostname sent by the
client.  If they don't match, the connection is refused.  If they match,
then sshd looks for a known host key for the client hostname.  Typically
the administrator setting up host-based authentication has manually
added this to /etc/ssh/ssh_known_hosts.

The ssh client is hardcoded to send the result of gethostname(2).  On
Debian systems, this is the short hostname, not the FQDN.  But that
causes a few problems with the above:

- When sshd looks up a hostname for the IP that's connecting it will
  typically get a FQDN in response, which won't match the short hostname
  provided by the client.  This means that in practice one always has to
  disable the lookup by setting HostbasedUsesNameFromPacketOnly to yes
  if you're expecting ssh clients on Debian hosts to try to connect.

- The entry added to /etc/ssh/ssh_known_hosts must be keyed by the short
  hostname, so that it can be successfully looked up.  But (at least in
  my mind) host keys are more properly associated with FQDNs not short
  hostnames, and in any case there is the potential for clashes, which
  is much less likely when indexing keys by FQDN.

I conjecture that that the way host-based authentication works in
OpenSSH implicitly assumes that gethostname(2) returns the FQDN, as it
does on some non-Debian GNU/Linux systems and perhaps other unixes.  If
that's right, then perhaps the OpenSSH client in Debian should be
patched to send the FQDN when doing host-based authentication.

-- 
Sean Whitton

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmC0EoMZHHNwd2hpdHRv
bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQM0wD/sHrREw2Wx4O6m8U9BryB+e
WLik1deBcwJppGgczRlqTNNyJk+331nV44sDC5UamwN0RJO+ML+Gdk5yjqn0wvOp
186nMIPdVQaXDzOfq0jzSrU8bblwRAkpgufs5xBHL4U2t8byVMY1aRSh+vTQTreZ
pvF1dQi+O33yT5nbsa5+faDo5LCVjCCU9S1RufJkeIjG2u069Kb3dm8/OEslePGP
Bif+Ow6ixHqxhNvb+NDI3AV3wCWCXJ7Et44972l9SRYM1gIfQB0aRnagY3Orxo1A
+XhFWvTrgJTNDiqLs3gLtsX5QpP7vTlkHzfQRDVWkMQrMH03KRCLvm6dGayfjMHq
lF47+O45xWNI76zxduog6eYKV+mNWTPbXKJGV3xI1fhUa47g4wW93k6sSTKrkOqN
Qk8SR3c/kMhfkOcQ6blG3ou6Dbny5SPGeE+iz3IPZRjAo4vCIYAtgIdE+A2rzNjC
PhrfJR9uzNzlts3EpVcpfNmMEB0lDqoO0VXVvfFUZQSF+TYMroEJSJgVSoWexMWZ
oNw/In+vmEXPLgWe0HjNI0zA1hPOVbIn7R+LHWJaYbXwJvpHDlBJzj5lH1L+Pboq
e3OdYf1fbxfKCah2quTbQyTGEYSJ8VkTOq8Y/7O7d4IyDg6biZLSSZVCGK2DdrbO
J+bzvU/JR7H6nWP5qC13kA==
=cj1K
-----END PGP SIGNATURE-----