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.