ECDSA and first connection; bug?

[Dan Kaminsky]

Not really.  ssh-keyscan is a leap of faith.

It's _technically_ feasible to do this:

1) Detect that there are other host key types
2) After logging in, run new ssh sessions off a port forward to
localhost:[original connection port, might not be 22]
3) Collect the new keys

Whether anyone wants to write this code, I don't know.  But it's
completely possible.


On Thu, Jan 27, 2011 at 2:03 PM, Markus Friedl <mfriedl at gmail.com> wrote:
> yes, this is what Damien wrote.
>
> Am 27.01.2011 um 17:38 schrieb Dan Kaminsky:
>
>> What you'd want is a protocol to upgrade from an old host key to a new host key, leveraging the existing trust in the old key.
>>
>> Everything else is just a new leap of faith, including ssh-keyscan.
>>
>> Sent from my iPhone
>>
>> On Jan 27, 2011, at 5:20 AM, Markus Friedl <markus.r.friedl at arcor.de> 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
>>>>
>>>> _______________________________________________
>>>> openssh-unix-dev mailing list
>>>> openssh-unix-dev at mindrot.org
>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>