> 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. -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
