ECDSA and first connection; bug?

[Markus Friedl]

I agree with Damien:

The current behaviour reduces the risks of a MITM attack and using
ssh-keyscan to collect the 'new' ECDSA is perfectly reasonable.

-m

On Tue, Jan 25, 2011 at 09:25:02AM +1100, Damien Miller wrote:
> 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
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev