> On Dec 2, 2016, at 12:27 AM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
>> On Dec 2, 2016, at 12:19 AM, Glyph Lefkowitz <gl...@twistedmatrix.com 
>> <mailto:gl...@twistedmatrix.com>> wrote:
>>> On Dec 1, 2016, at 7:01 PM, Mark Williams <markrwilli...@gmail.com 
>>> <mailto:markrwilli...@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.


Twisted-Python mailing list

Reply via email to