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

Mark Williams markrwilliams at gmail.com
Thu Dec 1 20:01:25 MST 2016


On Thu, Dec 01, 2016 at 05:11:37PM -0800, Craig Rodrigues wrote:
> Hi,
>
> I filed this bug:
> 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.

Thanks!

-Mark




More information about the Twisted-Python mailing list