ECDSA and first connection; bug?

[Damien Miller]

On Mon, 24 Jan 2011, Phil Pennock wrote:

> Folks,
> 
> I read the 5.7 release announcement and updated, to try out ECDSA.  Most
> parts worked very smoothly.  The inability to create SSHFP records is
> understandable, since IANA haven't allocated a code yet.
> 
> One apparent bug: I think StrictHostKeyChecking=ask is broken for ECDSA.
> 
> % ssh -o HostKeyAlgorithms=ecdsa-sha2-nistp256 localhost
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

This is deliberate. 

Previously, a malicious server could arrange for ssh(1) to display a
less-scary message for a changed hostkey if its host key happened to
be a different type to one that has already been learned.

Now there should be no surprises since ssh(1) will automatically request
hostkey type matching keys that are already known, though this does not
occur when you override HostkeyAlgorithms (like you did). We talked about
whether we should retain the old message in this case or not, but thought
the safest thing to do would be consistent with the non-explicit-
HostkeyAlgorithms case.

For learning different hostkey types, we recommend ssh-keyscan. I'd like to
do a protocol message for a server to send all its hostkeys to the client,
but this would require a KEX extension and I'm not sure how compatible
this would be with non-OpenSSH implementations.

-d