openssh unix dev - Jan 2011 - ECDSA and first connection; bug?

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!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
22:20:32:f8:fb:65:87:09:33:a9:b6:c9:b0:5e:14:b8.
Please contact your system administrator.
Add correct host key in /home/pdp/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/pdp/.ssh/known_hosts:2
ECDSA host key for localhost has changed and you have requested strict checking.
Host key verification failed.


No difference if I explicitly give { -o StrictHostKeyChecking=ask }.

If I have a host which I've connected to with RSA and then I connect
with DSS, then if recollection serves, I'll get a warning that there's
no known DSA key, I'll see the fingerprint for the RSA and DSA keys, and
get asked if I'm sure I want to continue.

For ECDSA, I can use ssh-keyscan, or manual hacking in of the pubkey
(from local disk) and things work.  But I shouldn't need to do this,
should I?

I saw the "automatically order the hostkeys requested by the client
based on which hostkeys are already recorded in known_hosts" note; that
manages to hide this problem, but if I explicitly ask, I should be able
to auth.

Am I missing something, or is this broken, with ssh(1) getting confused
about RSA keys vs ECDSA keys?

(fuller details of what I did at
 http://bridge.grumpy-troll.org/2011/01/openssh.html )

Thanks,
-Phil

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