[Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?
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
http://twistedmatrix.com/pipermail/twisted-python/2016-October/030819.html On Fri, Dec 2, 2016 at 9:11 AM, Craig Rodrigues <rodrigc@crodrigues.org> 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?
-- Craig
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
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 On Thu, Dec 1, 2016 at 5:24 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
http://twistedmatrix.com/pipermail/twisted-python/2016-October/030819.html
On Fri, Dec 2, 2016 at 9:11 AM, Craig Rodrigues <rodrigc@crodrigues.org> 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?
-- Craig
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
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
On Dec 1, 2016, at 7:01 PM, Mark Williams <markrwilliams@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
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' 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
On Dec 2, 2016, at 12:19 AM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Dec 1, 2016, at 7:01 PM, Mark Williams <markrwilliams@gmail.com <mailto:markrwilliams@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. -glyph
On Dec 2, 2016, at 12:27 AM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Dec 2, 2016, at 12:19 AM, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote:
On Dec 1, 2016, at 7:01 PM, Mark Williams <markrwilliams@gmail.com <mailto:markrwilliams@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
On Dec 2, 2016, at 12:37 AM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Dec 2, 2016, at 12:27 AM, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote:
On Dec 2, 2016, at 12:19 AM, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote:
On Dec 1, 2016, at 7:01 PM, Mark Williams <markrwilliams@gmail.com <mailto:markrwilliams@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.
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
On Fri, Dec 2, 2016 at 1:23 AM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
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.
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
On Fri, Dec 2, 2016 at 9:18 AM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
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'
This seems to be the problem. On this line: https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/keys.py#... 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/bac... https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/bac... However for EC keys, I do not see a 'key_size' attribute: https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/bac... 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
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/known... 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
On Dec 2, 2016, at 4:41 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
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 <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/known... <https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/client/known...>
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/e48500b94a3b3c751a4ccea36db95a45db8c... 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
On Friday, December 2, 2016, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
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.
I believe that I have fixed this in trunk. Can you try this with conch in trunk? This works for me in trunk: 1. Start with an empty ~/.ssh/known_hosts file , or one with an ecdsa key for myhost.com 2. ssh myhost.com 3. log out of myhost.com 3. see that ~/.ssh/known_hosts contains an ecdsa host key for myhost.com 4. conch myhost.com 5. successfully log into myhost.com with conch Before the latest fixes, I would get a bad host key error in step 5. Many thanks to the0id and acabhishek942 for providing the ecdsa fixes to conch. -- Craig
It works: $ conch twistedmatrix.com echo hooray hooray $ conch --version Twisted version: 16.6.0dev0 $ That's using an RSA host key though. It seems that the hosts I have using ECDSA keys (buildbot.twistedmatrix.com <http://buildbot.twistedmatrix.com/>, for example) still don't work with conch. Is that expected at this point? -glyph
On Dec 20, 2016, at 2:32 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Friday, December 2, 2016, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote: 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.
I believe that I have fixed this in trunk. Can you try this with conch in trunk?
This works for me in trunk:
1. Start with an empty ~/.ssh/known_hosts file , or one with an ecdsa key for myhost.com <http://myhost.com/> 2. ssh myhost.com <http://myhost.com/> 3. log out of myhost.com <http://myhost.com/> 3. see that ~/.ssh/known_hosts contains an ecdsa host key for myhost.com <http://myhost.com/> 4. conch myhost.com <http://myhost.com/> 5. successfully log into myhost.com <http://myhost.com/> with conch
Before the latest fixes, I would get a bad host key error in step 5.
Many thanks to the0id and acabhishek942 for providing the ecdsa fixes to conch.
-- Craig
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
I'm not sure. I was able to use conch to log into a box where the ecdsa key looked like this in my ~/.ssh/known_hosts 192.168.1.2 ecdsa-sha2-nistp256 XXXXXXXXXX -- Craig On Tue, Dec 20, 2016 at 4:10 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
It works:
$ conch twistedmatrix.com echo hooray hooray $ conch --version Twisted version: 16.6.0dev0 $
That's using an RSA host key though. It seems that the hosts I have using ECDSA keys (buildbot.twistedmatrix.com, for example) still don't work with conch. Is that expected at this point?
-glyph
On Dec 20, 2016, at 2:32 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Friday, December 2, 2016, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
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.
I believe that I have fixed this in trunk. Can you try this with conch in trunk?
This works for me in trunk:
1. Start with an empty ~/.ssh/known_hosts file , or one with an ecdsa key for myhost.com 2. ssh myhost.com 3. log out of myhost.com 3. see that ~/.ssh/known_hosts contains an ecdsa host key for myhost.com 4. conch myhost.com 5. successfully log into myhost.com with conch
Before the latest fixes, I would get a bad host key error in step 5.
Many thanks to the0id and acabhishek942 for providing the ecdsa fixes to conch.
-- Craig
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Here's buildbot's key: buildbot.twistedmatrix.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBcw4pr6WdgDMw7PbkvsuEdCqKQTtpLYPGoe7qkuQucuexYBiCkO/BeoB0wANX2cVmxUP0llpYJQL4w3cAR0csA= I think you should be able to validate that even if you can't auth :) -g
On Dec 20, 2016, at 4:54 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
I'm not sure. I was able to use conch to log into a box where the ecdsa key looked like this in my ~/.ssh/known_hosts
192.168.1.2 ecdsa-sha2-nistp256 XXXXXXXXXX
--
Craig
On Tue, Dec 20, 2016 at 4:10 PM, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote: It works:
$ conch twistedmatrix.com <http://twistedmatrix.com/> echo hooray hooray $ conch --version Twisted version: 16.6.0dev0 $
That's using an RSA host key though. It seems that the hosts I have using ECDSA keys (buildbot.twistedmatrix.com <http://buildbot.twistedmatrix.com/>, for example) still don't work with conch. Is that expected at this point?
-glyph
On Dec 20, 2016, at 2:32 PM, Craig Rodrigues <rodrigc@crodrigues.org <mailto:rodrigc@crodrigues.org>> wrote:
On Friday, December 2, 2016, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote: 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.
I believe that I have fixed this in trunk. Can you try this with conch in trunk?
This works for me in trunk:
1. Start with an empty ~/.ssh/known_hosts file , or one with an ecdsa key for myhost.com <http://myhost.com/> 2. ssh myhost.com <http://myhost.com/> 3. log out of myhost.com <http://myhost.com/> 3. see that ~/.ssh/known_hosts contains an ecdsa host key for myhost.com <http://myhost.com/> 4. conch myhost.com <http://myhost.com/> 5. successfully log into myhost.com <http://myhost.com/> with conch
Before the latest fixes, I would get a bad host key error in step 5.
Many thanks to the0id and acabhishek942 for providing the ecdsa fixes to conch.
-- Craig
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Ah, OK. In my testing, I had this in my server's /etc/ssh/sshd_config file to force use of ECDSA keys during my testing: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key If I then logged into the server with: *conch 192.168.1.2* , then having an ecdsa key in ~/.ssh/known_hosts worked fine and I could log in. Before the latest patches, the ecdsa keys were not being parsed properly and this never worked at all. If I changed the config on the server to: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key I got a bad host key error with conch, same as if I tried to log into buildbot.twistedmatrix.com. I put this: import pudb; pudb.set_trace() on this line inside *_continue_KEX_ECDH_REPLY()* : https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/transpor... What I then found was that on this line: hostkey, pubKey, signature, packet = getNS(packet, 3) The host key is an RSA key. Then this line in the same function: d = self.verifyHostKey(hostKey, fingerprint) tries to compare the hostKey for 192.168.1.2 (which is RSA), against the key in ~/.ssh/known_hosts which is ecdsa. It then fails and returns a bad host key error. I also get this problem when trying to do *conch buildbot.twistedmatrix.com <http://buildbot.twistedmatrix.com>* -- Craig On Tue, Dec 20, 2016 at 5:13 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Here's buildbot's key:
buildbot.twistedmatrix.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBcw4pr6 WdgDMw7PbkvsuEdCqKQTtpLYPGoe7qkuQucuexYBiCkO/ BeoB0wANX2cVmxUP0llpYJQL4w3cAR0csA=
I think you should be able to validate that even if you can't auth :)
-g
On Dec 20, 2016, at 4:54 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
I'm not sure. I was able to use conch to log into a box where the ecdsa key looked like this in my ~/.ssh/known_hosts
192.168.1.2 ecdsa-sha2-nistp256 XXXXXXXXXX
--
Craig
On Tue, Dec 20, 2016 at 4:10 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
It works:
$ conch twistedmatrix.com echo hooray hooray $ conch --version Twisted version: 16.6.0dev0 $
That's using an RSA host key though. It seems that the hosts I have using ECDSA keys (buildbot.twistedmatrix.com, for example) still don't work with conch. Is that expected at this point?
-glyph
On Dec 20, 2016, at 2:32 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Friday, December 2, 2016, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
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.
I believe that I have fixed this in trunk. Can you try this with conch in trunk?
This works for me in trunk:
1. Start with an empty ~/.ssh/known_hosts file , or one with an ecdsa key for myhost.com 2. ssh myhost.com 3. log out of myhost.com 3. see that ~/.ssh/known_hosts contains an ecdsa host key for myhost.com 4. conch myhost.com 5. successfully log into myhost.com with conch
Before the latest fixes, I would get a bad host key error in step 5.
Many thanks to the0id and acabhishek942 for providing the ecdsa fixes to conch.
-- Craig
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Dec 20, 2016, at 5:50 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
Ah, OK. In my testing, I had this in my server's /etc/ssh/sshd_config file to force use of ECDSA keys during my testing:
# HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key
If I then logged into the server with: conch 192.168.1.2
, then having an ecdsa key in ~/.ssh/known_hosts worked fine and I could log in. Before the latest patches, the ecdsa keys were not being parsed properly and this never worked at all.
If I changed the config on the server to:
# HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key
I got a bad host key error with conch, same as if I tried to log into buildbot.twistedmatrix.com <http://buildbot.twistedmatrix.com/>. I put this:
import pudb; pudb.set_trace()
on this line inside _continue_KEX_ECDH_REPLY() : https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/transpor... <https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/transpor...> Did you mean https://github.com/twisted/twisted/blob/71643ca93e024d33dba8de9eef149876554c... <https://github.com/twisted/twisted/blob/71643ca93e024d33dba8de9eef149876554c...> ?
What I then found was that on this line:
hostkey, pubKey, signature, packet = getNS(packet, 3)
The host key is an RSA key. Then this line in the same function: d = self.verifyHostKey(hostKey, fingerprint)
tries to compare the hostKey for 192.168.1.2 (which is RSA), against the key in ~/.ssh/known_hosts which is ecdsa. It then fails and returns a bad host key error.
I also get this problem when trying to do conch buildbot.twistedmatrix.com <http://buildbot.twistedmatrix.com/> So... is this because buildbot.twistedmatrix.com <http://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
-- Craig
On Tue, Dec 20, 2016 at 5:13 PM, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote: Here's buildbot's key:
buildbot.twistedmatrix.com <http://buildbot.twistedmatrix.com/> ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBcw4pr6WdgDMw7PbkvsuEdCqKQTtpLYPGoe7qkuQucuexYBiCkO/BeoB0wANX2cVmxUP0llpYJQL4w3cAR0csA=
I think you should be able to validate that even if you can't auth :)
-g
On Dec 20, 2016, at 4:54 PM, Craig Rodrigues <rodrigc@crodrigues.org <mailto:rodrigc@crodrigues.org>> wrote:
I'm not sure. I was able to use conch to log into a box where the ecdsa key looked like this in my ~/.ssh/known_hosts
192.168.1.2 ecdsa-sha2-nistp256 XXXXXXXXXX
--
Craig
On Tue, Dec 20, 2016 at 4:10 PM, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote: It works:
$ conch twistedmatrix.com <http://twistedmatrix.com/> echo hooray hooray $ conch --version Twisted version: 16.6.0dev0 $
That's using an RSA host key though. It seems that the hosts I have using ECDSA keys (buildbot.twistedmatrix.com <http://buildbot.twistedmatrix.com/>, for example) still don't work with conch. Is that expected at this point?
-glyph
On Dec 20, 2016, at 2:32 PM, Craig Rodrigues <rodrigc@crodrigues.org <mailto:rodrigc@crodrigues.org>> wrote:
On Friday, December 2, 2016, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote: 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.
I believe that I have fixed this in trunk. Can you try this with conch in trunk?
This works for me in trunk:
1. Start with an empty ~/.ssh/known_hosts file , or one with an ecdsa key for myhost.com <http://myhost.com/> 2. ssh myhost.com <http://myhost.com/> 3. log out of myhost.com <http://myhost.com/> 3. see that ~/.ssh/known_hosts contains an ecdsa host key for myhost.com <http://myhost.com/> 4. conch myhost.com <http://myhost.com/> 5. successfully log into myhost.com <http://myhost.com/> with conch
Before the latest fixes, I would get a bad host key error in step 5.
Many thanks to the0id and acabhishek942 for providing the ecdsa fixes to conch.
-- Craig
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Tue, Dec 20, 2016 at 6:24 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
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. I started a test instance of the sshd server with: /usr/sbin/sshd -p 9000 -d -d -d and captured the logs (see attached). I think some problems are: (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
On Tue, Dec 20, 2016 at 7:32 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Tue, Dec 20, 2016 at 6:24 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
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.
I started a test instance of the sshd server with:
/usr/sbin/sshd -p 9000 -d -d -d
and captured the logs (see attached).
I think some problems are: (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.
On Dec 20, 2016, at 7:32 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Tue, Dec 20, 2016 at 6:24 PM, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote:
So... is this because buildbot.twistedmatrix.com <http://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.
I started a test instance of the sshd server with:
/usr/sbin/sshd -p 9000 -d -d -d
and captured the logs (see attached).
I think some problems are: (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.
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, -glyph
On Wed, Dec 21, 2016 at 4:46 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
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
On Dec 21, 2016, at 5:40 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Wed, Dec 21, 2016 at 4:46 PM, Glyph Lefkowitz <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote:
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
On Fri, Jan 20, 2017 at 10:21 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
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
On Thu, Dec 1, 2016 at 7:01 PM, Mark Williams <markrwilliams@gmail.com> wrote:
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/transpor... 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
On Dec 3, 2016, at 4:21 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Thu, Dec 1, 2016 at 7:01 PM, Mark Williams <markrwilliams@gmail.com <mailto:markrwilliams@gmail.com>> wrote:
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/transpor... <https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/transpor...> 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 <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
participants (4)
-
Craig Rodrigues -
Glyph Lefkowitz -
Mark Williams -
Oon-Ee Ng