[Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?

Glyph Lefkowitz glyph at twistedmatrix.com
Fri Dec 2 01:37:31 MST 2016


> On Dec 2, 2016, at 12:27 AM, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> 
> 
>> On Dec 2, 2016, at 12:19 AM, Glyph Lefkowitz <glyph at twistedmatrix.com <mailto:glyph at twistedmatrix.com>> wrote:
>> 
>> 
>>> On Dec 1, 2016, at 7:01 PM, Mark Williams <markrwilliams at gmail.com <mailto:markrwilliams at gmail.com>> wrote:
>>> 
>>> On Thu, Dec 01, 2016 at 05:11:37PM -0800, Craig Rodrigues wrote:
>>>> Hi,
>>>> 
>>>> I filed this bug:
>>>> https://twistedmatrix.com/trac/ticket/8931 <https://twistedmatrix.com/trac/ticket/8931>
>>>> 
>>>> At least for me, conch fails to parse a host key created by OpenSSH
>>>> in ~/.ssh/known_hosts
>>>> which is of type ecdsa-sha2-nistp256.
>>>> 
>>>> Anyone have an idea as to how to fix this?
>>>> 
>>> 
>>> As usual you've found a fantastically interesting issue.
>>> 
>>> This is conch, the client, right?  I'm guessing so because
>>> ~/.ssh/known_hosts contains the servers the ssh client trusts.
>>> (Specifically, among other things it contains a hostname and that
>>> host's sshd server's public key fingerprint).
>>> 
>>> If it is conch, the-client, then deleting the offending entry from
>>> ~/.ssh/known_hosts and getting a new one makes sense.  That's because
>>> sshd usually generates a couple of different keys in case clients
>>> don't support the latest and greatest technology.
>>> 
>>> I think deleting the entry in ~/.ssh/known_hosts allows conch to ask
>>> the server for a different key that it *can* understand.  You should
>>> be able to find out which server key conch negotiated by doing thing
>>> following after deleting the offending ~/.ssh/known_hosts entry:
>>> 
>>> (<hostname is the problematic OS X server>)
>>> $ ssh-keygen -H -F <hostname> | awk '{ print $NF }'
>>> dGhpcyBpcyB2ZXJ5IHZlcnkgdmVyeSB2ZXJ5IHZlcnkgbG9uZyBob3N0IGtleQ==
>>> 
>>> Then on the OS X server, grep for that in /etc/ssh/*.pub
>>> 
>>> I bet the key negotiated by conch is not an ECDSA key but rather an
>>> RSA key.  If this is all the case, then I think you've found a key
>>> that LibreSSL supports but your client's libssl (which conch calls
>>> into via cryptography) does not.  What version of libssl do you have?
>>> 
>>> If any of this is helpful or relevant I'll ask more questions in the
>>> ticket.
>> 
>> I think there might be a regression in 16.6.0.
>> 
>> For every version up to 16.6.0, I can do 'conch twistedmatrix.com <http://twistedmatrix.com/>' in a shell and it works fine.
>> 
>> On 16.6.0, I get:
>> 
>> Connection to twistedmatrix.com <http://twistedmatrix.com/> closed.
>> conch: exiting with error [Failure instance: Traceback (failure with no frames): <class 'twisted.conch.error.ConchError'>: ('bad host key', 9)
>> ]
>> 
>> instead.
>> 
>> Worth noting: the keys I have for twistedmatrix.com <http://twistedmatrix.com/> are RSA keys.
>> 
>> What did we add recently that changes key parsing?
> 
> The offending commit is 8164d89104a453947215b9296e8b406f15e63252.  Clearly something went wrong when introducing ECDSA parsing.

The problem is not quite as bad as breaking RSA parsing, at least; the issue is that my known_hosts file includes an ecdsa-sha2-nistp256 entry that _precedes_ my ssh-rsa entry.  So the problem is that parsing one of those entries raises an exception which propagates.  From a superficial investigation, it would appear that _all_ ecdsa keys cause this failure, though.

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20161202/3d42e444/attachment-0002.html>


More information about the Twisted-Python mailing list