ECDSA and first connection; bug?

[Roumen Petrov]

Markus Friedl wrote:
> 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
>>      
I disagree with analysis.

The issue don't require user to change default settings .
The test case is simple :
- install versions < 5.7 on both sides;
- perform one connection from client;
- upgrade both systems
=> above message and connection refused.

So after upgrade users could either change HostKeyAlgorithms to the old 
ones or to upgrade to new server key.

Roumen


-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/