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

[Craig Rodrigues]

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?

--
Craig

[Oon-Ee Ng]

http://twistedmatrix.com/pipermail/twisted-python/2016-October/030819.html

Post by Craig Rodrigues
Hi,
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?
--
Craig
_______________________________________________
Twisted-Python mailing list
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Craig Rodrigues]

I don't think that is it. It is failing to parse an existing key generated
by OpenSSH.
If I delete the known_hosts file, conch generates a key which it ca parse.

--
Craig

Post by Oon-Ee Ng
http://twistedmatrix.com/pipermail/twisted-python/2016-October/030819.html

Post by Craig Rodrigues
Hi,
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?
--
Craig
_______________________________________________
Twisted-Python mailing list
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

_______________________________________________
Twisted-Python mailing list
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Mark Williams]

Post by Craig Rodrigues
Hi,
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

[Glyph Lefkowitz]

Post by Mark Williams

Post by Craig Rodrigues
Hi,
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
(<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' in a shell and it works fine.

On 16.6.0, I get:

Connection to 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 are RSA keys.

What did we add recently that changes key parsing?

-glyph

[Glyph Lefkowitz]

Post by Glyph Lefkowitz

Post by Mark Williams

Hi,
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
(<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.
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.

-glyph

[Glyph Lefkowitz]

Post by Glyph Lefkowitz

Post by Glyph Lefkowitz

Post by Mark Williams

Hi,
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
(<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.
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

[Glyph Lefkowitz]

Post by Glyph Lefkowitz

Post by Glyph Lefkowitz

Post by Glyph Lefkowitz

Post by Mark Williams

Hi,
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
(<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.
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.

Investigating further, I think I've figured it out. Here's a patch that fixes the problem:

diff --git a/src/twisted/conch/ssh/keys.py b/src/twisted/conch/ssh/keys.py
index d47db7f..570f524 100644
--- a/src/twisted/conch/ssh/keys.py
+++ b/src/twisted/conch/ssh/keys.py
@@ -247,8 +247,10 @@ class Key(object):
).public_key(default_backend())
)
elif keyType in [b'ecdsa-sha2-' + curve for curve in list(_curveTable.keys())]:
- x, y, rest = common.getMP(rest, 2)
- return cls._fromECComponents(x=x, y=y, curve=keyType)
+ return cls(load_ssh_public_key(
+ keyType + b' ' + base64.encodestring(blob),
+ default_backend())
+ )
else:
raise BadKeyError('unknown blob type: %s' % (keyType,))

I suspect, but do not fully understand, that the problem here is point compression. Key._fromString_BLOB naively just does getMP(blob, 2) and expects that the x,y will be the EC point. However, to quote https://tools.ietf.org/html/rfc5656#section-3.1, "point compression MAY be used". I don't know exactly how point compression works, but I do understand that it means you do funky stuff with the Y value. I do not believe that EllipticCurvePrivateNumbers understands said funky stuff.

A specific ECC integration test with ssh-keygen from OpenSSH and twisted.conch.client.knownhosts.KnownHostsFile would have spotted this specific manifestation of the issue. However, another underlying bug is that KnownHostsFile _should_ ignore lines that it can't parse. And, there's another potential manifestation of the issue where loading from an actual key blob might not work; arguably the problem here is that KnownHostsFile made the questionable decision to do its own base64-decoding and pass the blob straight to the key rather than just pass the portion of the line after the hostname and load it as an openssh-format key directly.

-glyph

[Craig Rodrigues]

Post by Glyph Lefkowitz
diff --git a/src/twisted/conch/ssh/keys.py b/src/twisted/conch/ssh/keys.py
index d47db7f..570f524 100644
--- a/src/twisted/conch/ssh/keys.py
+++ b/src/twisted/conch/ssh/keys.py
).public_key(default_backend())
)
elif keyType in [b'ecdsa-sha2-' + curve for curve in
- x, y, rest = common.getMP(rest, 2)
- return cls._fromECComponents(x=x, y=y, curve=keyType)
+ return cls(load_ssh_public_key(
+ keyType + b' ' + base64.encodestring(blob),
+ default_backend())
+ )
raise BadKeyError('unknown blob type: %s' % (keyType,))
I suspect, but do not fully understand, that the problem here is point
compression. Key._fromString_BLOB naively just does getMP(blob, 2) and
expects that the x,y will be the EC point. However, to quote
https://tools.ietf.org/html/rfc5656#section-3.1, "point compression MAY
be used". I don't know exactly how point compression works, but I do
understand that it means you do funky stuff with the Y value. I do not
believe that EllipticCurvePrivateNumbers understands said funky stuff.
A specific ECC integration test with ssh-keygen from OpenSSH and
twisted.conch.client.knownhosts.KnownHostsFile would have spotted this
specific manifestation of the issue. However, another underlying bug is
that KnownHostsFile _should_ ignore lines that it can't parse. And,
there's another potential manifestation of the issue where loading from an
actual key blob might not work; arguably the problem here is that
KnownHostsFile made the questionable decision to do its own base64-decoding
and pass the blob straight to the key rather than just pass the portion of
the line after the hostname and load it as an openssh-format key directly.

Yes, you are on the right track. As the known_hosts file is parsed line by
line,
if an exception is thrown during parsing, then any valid keys further in
the file are ignored,
and you get the "bad host key" error.

I tried your patch, and while I don't get the same error, the patch doesn't
solve the problem for me.

I did some more debugging, and when I tried to put some print statements in
the code to
figure out what is going on, I found these errors:

Traceback (most recent call last):


File "<pudb command line>", line 1, in <module>
File "/Users/crodrigues/twisted8/src/twisted/conch/ssh/keys.py", line
787, in __repr__
self._keyObject.key_size)]

AttributeError: '_EllipticCurvePublicKey' object has no attribute
'key_size'


and also this:

File "/Users/crodrigues/twisted8/src/twisted/conch/client/knownhosts.py",
line 107, in matchesKey
print("SELF.PUBLICKEY ", self.publickey)
AttributeError: 'PlainEntry' object has no attribute 'publickey'

--
Craig

[Craig Rodrigues]

Post by Craig Rodrigues
File "<pudb command line>", line 1, in <module>
File "/Users/crodrigues/twisted8/src/twisted/conch/ssh/keys.py", line
787, in __repr__
self._keyObject.key_size)]
AttributeError: '_EllipticCurvePublicKey' object has no attribute
'key_size'

This seems to be the problem.

On this line:
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/keys.py#L782
the __repr__() function wants to call the key_size() method.

This seems to exist for DSA and RSA keys:
https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/backends/openssl/dsa.py#L232
https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/backends/openssl/rsa.py#L482

However for EC keys, I do not see a 'key_size' attribute:
https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/backends/openssl/ec.py#L256

When trying to compare the known host key, the code tries to do a
__repr__() and it fails,
so this doesn't seem to work with EC keys.

--
Craig

[Craig Rodrigues]

Glyph,

I took your fix, and added some fixes of my own for __repr__() printing of
EC keys in this branch:

https://github.com/twisted/twisted/pull/615


If I run the tests, I get a new failure:


trial twisted.conch.test.test_keys.KeyTests.test_fromBlobECDSA

Traceback (most recent call last):
File "/Users/crodrigues/twisted_15/src/twisted/conch/test/test_keys.py",
line 776, in test_fromBlobECDSA
eckey = keys.Key.fromString(ecblob)
File "/Users/crodrigues/twisted_15/src/twisted/conch/ssh/keys.py", line
197, in fromString
return method(data)
File "/Users/crodrigues/twisted_15/src/twisted/conch/ssh/keys.py", line
253, in _fromString_BLOB
default_backend()))
File
"/Users/crodrigues/venv-3.6/lib/python3.6/site-packages/cryptography/hazmat/primitives/serialization.py",
line 69, in load_ssh_public_key
return loader(key_type, rest, backend)
File
"/Users/crodrigues/venv-3.6/lib/python3.6/site-packages/cryptography/hazmat/primitives/serialization.py",
line 103, in _load_ssh_ecdsa_public_key
'Key header and key body contain different key type values.'

builtins.ValueError: Key header and key body contain different key type
values.


Also, if I try to access my machine with:
conch 192.168.1.2

I see that in the matchesKey() function on this line:
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/client/knownhosts.py#L106

self.publicKey is an EC key, while keyObject is an RSA key.

Therefore this function always fails, and I cannot log into the box.

Any ideas?

Thanks.
--
Craig

[Glyph Lefkowitz]

Post by Craig Rodrigues
Glyph,
https://github.com/twisted/twisted/pull/615 <https://github.com/twisted/twisted/pull/615>
trial twisted.conch.test.test_keys.KeyTests.test_fromBlobECDSA
File "/Users/crodrigues/twisted_15/src/twisted/conch/test/test_keys.py", line 776, in test_fromBlobECDSA
eckey = keys.Key.fromString(ecblob)
File "/Users/crodrigues/twisted_15/src/twisted/conch/ssh/keys.py", line 197, in fromString
return method(data)
File "/Users/crodrigues/twisted_15/src/twisted/conch/ssh/keys.py", line 253, in _fromString_BLOB
default_backend()))
File "/Users/crodrigues/venv-3.6/lib/python3.6/site-packages/cryptography/hazmat/primitives/serialization.py", line 69, in load_ssh_public_key
return loader(key_type, rest, backend)
File "/Users/crodrigues/venv-3.6/lib/python3.6/site-packages/cryptography/hazmat/primitives/serialization.py", line 103, in _load_ssh_ecdsa_public_key
'Key header and key body contain different key type values.'
builtins.ValueError: Key header and key body contain different key type values.
conch 192.168.1.2
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/client/knownhosts.py#L106 <https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/client/knownhosts.py#L106>
self.publicKey is an EC key, while keyObject is an RSA key.
Therefore this function always fails, and I cannot log into the box.
Any ideas?

It looks like https://github.com/twisted/twisted/blob/e48500b94a3b3c751a4ccea36db95a45db8c34be/src/twisted/conch/client/knownhosts.py#L434-L446 isn't really geared towards the idea that there might be multiple entries for one host. The first step toward a fix would be to correct that algorithm to only fail if no matches are found, or to specifically check the key type before failing.

-glyph

[Craig Rodrigues]

Can you file a new ticket for each of these? The ordering thing seems
super low priority, but not being able to receive multiple host keys is
definitely a spec violation.
Thanks for figuring it out,

Can you try these two patches, combined in one workspace ?

https://github.com/twisted/twisted/pull/640
https://github.com/twisted/twisted/pull/642

--
Craig

[Glyph Lefkowitz]

Can you file a new ticket for each of these? The ordering thing seems super low priority, but not being able to receive multiple host keys is definitely a spec violation.
Thanks for figuring it out,
Can you try these two patches, combined in one workspace ?
https://github.com/twisted/twisted/pull/640 <https://github.com/twisted/twisted/pull/640>
https://github.com/twisted/twisted/pull/642 <https://github.com/twisted/twisted/pull/642>

I finally got around to trying this, and was baffled as to why the behavior wasn't different between trunk and trunk-with-merged-PRs; then I realized the commits from both were already in trunk :-). Seems to work great now vs. 16.0 - thank you for fixing this!

-glyph

[Craig Rodrigues]

Post by Glyph Lefkowitz
I finally got around to trying this, and was baffled as to why the
behavior wasn't different between trunk and trunk-with-merged-PRs; then I
realized the commits from both were already in trunk :-). Seems to work
great now vs. 16.0 - thank you for fixing this!

Many thanks to the0id Abhishek Choudhary for doing this to add ECDSA
support to conch.
I just fixed up some of the rough edges in conch.

One minor thing I noticed about conch that deviates from the OpenSSH client
is that conch wants to write two entries in ~/.ssh/known_hosts for each
host it
connects to:
- one entry for the hostname
- one entry for the IP address

If the entry doesn't exist already, then the encoded form of the hostname
is written, so it looks like:

|1|8QluEPLDr6TMoscEvJPcpzFGhGo=|5wLvN+5WhahGWukK2XtBFd/tjaQ=
ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBmhQ2+fYcGOOdLqOsRQ5wzvQjP9K1tpF9+UTwLi9UIBIWOySfJBDtkZvycrIYcNolofySA//ffJA4ka0EvfAbg=

|1|EHrWwxCedWehiySnBrsY8YW/9TE=|uDqYMkrF0rvXgQIdDsUhBgPzKEo=
ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBmhQ2+fYcGOOdLqOsRQ5wzvQjP9K1tpF9+UTwLi9UIBIWOySfJBDtkZvycrIYcNolofySA//ffJA4ka0EvfAbg=
This seems quite weird to me, and I'm not sure why this behavior was
implemented
differently from the OpenSSH client.

I didn't change this behavior, though.
--
Craig

[Craig Rodrigues]

So... is this because buildbot.twistedmatrix.com has an RSA key as well,
and when it offers it, our checking isn't correctly comparing the type
before deciding that it doesn't match, or allowing for multiple keys? I
notice that if I manually add the RSA key and delete the ECDSA key it seems
to work.
-g

Yes, that is part of it.
What is happening is that the conch client sends a MSG_KEXINIT
packet to the server to negotatiate what the host key should be.
If I use an OpenSSH ssh client to connect to OpenSSH sshd server,
the negotiated host key algorithm is ecdsa-sha2-nistp256.
If I use a conch client to connect to the OpenSSH sshd server,
the negotiated host key algorithm is ssh-rsa.
/usr/sbin/sshd -p 9000 -d -d -d
and captured the logs (see attached).
(1) conch proposes a list of *host key algorithms* in a different
order than
OpenSSH. It shouldn't matter, but conch proposes ssh-rsa first,
while OpenSSH proposes it last.
(2) OpenSSH client seems to be able to receive multiple host keys back
from the server, and can match the one it has.
--
Craig

Here are the proper logs.

[Craig Rodrigues]

Post by Mark Williams
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?

Yes, you are right. I did some debugging and found that
in ssh_KEX_DH_GEX_REPLY()
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/transport.py#L1596
only an RSA key is negotiated, even if an EC key is in the known_hosts file.

I thought that with all the EC fixes committed to the tree that this was
all working,
but it looks like there is still some stuff missing. This might fill in
the gaps:

https://github.com/twisted/twisted/pull/432

--
Craig

[Glyph Lefkowitz]

Post by Mark Williams
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?
Yes, you are right. I did some debugging and found that in ssh_KEX_DH_GEX_REPLY()
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/transport.py#L1596 <https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/transport.py#L1596>
only an RSA key is negotiated, even if an EC key is in the known_hosts file.
I thought that with all the EC fixes committed to the tree that this was all working,
https://github.com/twisted/twisted/pull/432 <https://github.com/twisted/twisted/pull/432>

Yep. The stuff that got merged was intentionally, explicitly a subset of full EC functionality. We're trying to get it landed in stages, since, as you have already seen, even a partial implementation is very tricky to review :)

-glyph