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