Can we have better ssh fingerprint collision messages?

[Reindl Harald]

Am 12.11.2013 03:11, schrieb Chris Adams:
> Once upon a time, Reindl Harald <h.reindl at thelounge.net> said:
>> these lines are not written by hand and i replaced the key from "AAA" to "=="
>> of the first one with the  key off a completly different host in the file
>> resulting in the message i posted by ssh "harry at srv-rhsoft"
> 
> Replacing characters is making entries "by hand".  Replacing the first
> characters with "==" creates an invalid key (it is base64 encoded which
> cannot have "=" characters except at the end for padding as needed); it
> could be OpenSSH ignores invalid lines (I don't know).

jesus christ *from* "AAA" *to* "==" means *the whole valid key*
because quote two complete keys is a little bit long

so what is there invalid

>>> If there is no match to the host, you get the output you described; if
>>> there is a match but the key is different, you get the original poster's
>>> desired output.  This is standard (and I believe non-configurable)
>>> OpenSSH behavior going back to the beginning (and IIRC to the original
>>> SSH code before OpenSSH started)
>>
>> and as i have proven this is *not true* in all situations - period
> 
> That is incorrect.  The way to "prove" it is to connect to a host,
> change its host key (easiest way is to move /etc/ssh/*key* aside and
> restart sshd), and connect again.

you ssh command must have some magic that it can distinct if the
server changed it's key or the one in "known_hosts"

> Otherwise, show a case that didn't involve editing the known_hosts file.
> The OpenSSH code only works one way

and now you can explain me where is the difference in the key on the
server has changed and having a different but valid key than the
servers one on "known_hosts"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131112/0055284d/attachment.sig>