Dear Maintainer,

The openssh client included with Debian 8 is overly sensitive to the
extra intervening whitespace characters between the key type and the
value in the known_hosts file.
To me, this is a known problem for *this* version of openssh.
An older version (6.1p1, release 11.fc18, included with Fedora Core
18) did not have this problem.
The version that comes with Debian 7 (1:6.0p1-4+deb7u2) did not have
this issue as well.

For example, consider this entry in ~/.ssh/known_hosts:

    192.168.0.120 ecdsa-sha2-nistp256 AAAAE2Vj...=

Here, 192.168.0.120 is the IP address or hostname (doesn't matter; the
failure does not pertain that).
The ecdsa-sha2-nistp256 is the type of the host public key, and
AAAAE2Vj...= represents the value of the key.
That entry works fine.
If I add an extra whitespace between the IP address and the key type,
it still works fine:

    192.168.0.120  ecdsa-sha2-nistp256 AAAAE2Vj...=

But if I add the extra whitespace after the word
"ecdsa-sha2-nistp256", then the host key matching fails.

    192.168.0.120 ecdsa-sha2-nistp256  AAAAE2Vj...=

The 'ssh -vvv 192.168.0.120' will print, among others,

    debug3: load_hostkeys: loading entries for host "192.168.0.120"
from file "/home/user/.ssh/known_hosts"
    debug3: load_hostkeys: loaded 0 keys

So it failed to load the key for some reason.


This is an unwanted behavior, as I tend to keep ~/.ssh/known_hosts in
a column-aligned fashion, which means I introduce extra whitespaces
everywhere between items.

A cursory look into the source code tracks the possible error here
(in file:function format):
- hostfile.c:hostfile_read_key
- key.c:key_read
- sshkey.c:sshkey_read

It looks like the bug is in the last function.


Thanks,
Wirawan