RSA key auth failing from paramiko 2.9.x client to dropbear server #1961
Comments
|
We have the same issue.. Will try to get more debugging logs. |
|
After seeing the demo code, I found that using Doing some more testing, |
|
Does the server actually fail to announce the algorithm list or paramiko fails to parse it? |
|
same issue here, working in version 2.8.1 |
|
According to https://matt.ucc.asn.au/dropbear/CHANGES, Dropbear 2020.79 supports rsa-sha2 signatures. Are you using what version of dropbear? Also, changelog of paramiko says:
Currently, it is need to use disabled_algorithms to connect to old ssh server. |
|
As you can see from log its Debian OpenSSH not Dropbear.
|
|
When I connect with so it looks like paramiko is failing to handle this properly. The dropbear version currently being used in cirros is 2018.76, it will certainly make sense towards an update on that end, too. |
|
Same issue here using fabric with a proxy jump. |
|
Workaround is to set t = paramiko.Transport(sock)
# workaround for #1961
if hasattr(t, 'server_extensions'):
t.server_extensions = {'server-sig-algs': 'ssh-rsa'}
t.start_client()I consider that the following patch will fix the issue without use of disabled_algorithms by the user. diff --git a/paramiko/transport.py b/paramiko/transport.py
index b99b3278d..141192eeb 100644
--- a/paramiko/transport.py
+++ b/paramiko/transport.py
@@ -679,6 +679,9 @@ class Transport(threading.Thread, ClosingContextManager):
`.SSHException` -- if negotiation fails (and no ``event`` was
passed in)
"""
+ # backwards-compatibility for old ssh servers which doesn't send
+ # server-sig-algs in MSG_EXT_INFO.
+ self.server_extensions = {"server-sig-algs": "ssh-rsa"}
self.active = True
if event is not None:
# async, return immediately and let the app poll for completion |
|
I believe the problem is that Paramiko does not handle correctly an absence of |
|
I can confirm that I still hit the same/similar bug on version 2.9.1 using RSA keys. If we switch to password login it does work. Here's the debug trace: Fails: Works: Also tried with settings: Which does change the Key exchange agreements, but I still get the same error: Code in Cisco device does not support |
|
@teunis90 My answer as Stack Overflow question linked in my previous comment shows how to workaround the issue. |
|
Thanks @martinprikryl this fixed my issue! |
Fix `paramiko.ssh_exception.SSHException: encountered RSA key, expected OPENSSH key` error, which is due to paramiko/paramiko#1961 .
Fix `paramiko.ssh_exception.SSHException: encountered RSA key, expected OPENSSH key` error, which is due to paramiko/paramiko#1961 .
|
Ran into this issue as well. Have downgraded and pinned 2.8.1 for now. |
|
As @jun66j5 notes, this can be worked around w/o any patches by using the Modern OpenSSH versions' default behaviors, and the RFC this feature is based on, all suggest that at some point this sort of cut-over needs to happen (prefer SHA2 instead of SHA1) and I judged it was worthwhile to do so now, given that users can use the above-mentioned setting to revert to the prior behavior. That said, some of these comments sound like there are still actual bugs lurking in the implementation, so I'll be trying to replicate some of those scenarios and looking at other recent filed issues in case we need a 2.9.2 release. |
OK, this seems to be OpenSSH 6.7 (Debian Jessie) which I don't believe supports Tho I agree that log message is misleading so I'll patch it up. |
|
When doing that I found a minor enhancement where we can raise an exception earlier if the server does send a signature list and we happen to not have any overlap. I expect this will not be a common case but the new logic flow strongly suggested it, so I put it in. (Will be in changelog.) Anyway, for the case most of y'all are having, this is the new log output: It's not a perfect fix but hopefully it will guide more users to what's still the current suggested workaround. And when that workaround is in use, you'll get this (reckon I could try to do more state tracking so the 'NOTE' is only emitted on error, but Paramiko's current design would make that complex so it's not currently worth it): (Also - update your servers! 😱 SHA1 is broken!) |
|
Another note, I expect in some post-3.0 release (which will be the next "feature level" release with a drop of Python 2 and probably a small number of related tweaks) I will get to the much needed auth and algorithm-configuration overhauls I've been planning basically since I took this over. When that happens it should be much easier to specify ENABLED algorithms in addition to DISABLED ones, which will smooth over this kind of problem a bit more as well. |
|
2.9.2 now out with the above. I'm going to close this as "WONTFIX". If anyone can identify legit issues with the new feature that are not fixable by using |
As documented in paramiko/paramiko#1961 there is an incompatibility between Paramiko 2.9+ and dropbear (the SSH server used on Remarkable) when negotiating the pubkey algorithm. This fixes the issue by disabling SHA-2 algorithms, causing Paramiko to offer a SHA-1 algorithm which Dropbear will accept.
As documented in paramiko/paramiko#1961 there is an incompatibility between Paramiko 2.9+ and dropbear (the SSH server used on Remarkable) when negotiating the pubkey algorithm. This fixes the issue by disabling SHA-2 algorithms, causing Paramiko to offer a SHA-1 algorithm which Dropbear will accept.
|
What about the following situation? A system has devices running both newer and older versions of dropbear. We can apply the fix I think a good solution could be to change this code as follows: paramiko/paramiko/transport.py Lines 1338 to 1343 in f2b4be8 if isinstance(hostkey, RSAKey):
self._preferred_keys = self.preferred_rsa_keysAnd allow us to pass a list of Sometimes old routers cannot be upgraded because they're EOL, but customers may want to keep using them in their internal network which they consider secure for internal usage by their employees. It wouldn't be great to force them to throw those away just because of this, sooner or later these routers will die anyway but it's better to have an easier way to maintain backward compatibility and support them. |
|
@nemesisdesign This seems like a sensible feature request to consider. Can you repost as a new issue on the repo, with a link back to your comment here? Thanks! |
bug paramiko paramiko/paramiko#1961
Most tobiko tests are failing on RHEL9 environments due to ssh auth issues. It was found that with newer paramiko version the issues do not occur. There is an open issue[1] in Paramiko starting from 2.9.2 (which allows to connect to new servers like the one of RHEL 9) but in the while it brakes the support for the old CirrOS image server (image version 5.2). To keep support for old version we now uses disable_algorithms[1] option when creating an SSH connection to CirrOS images. The workaround has been documented in the Paramiko project page [2] [1] paramiko/paramiko#1961 [2] https://github.com/rhevm-qe-automation/python-rrmngmnt/pull/149/files#diff-7b3ed02bc73dc06b7db906cf97aa91dec2b2eb21f2d92bc5caa761df5bbc168f Change-Id: I301c18a832a05ddfd331bddd7ad2bc839205ad2d
|
Is anyone aware if there's an option I could throw into the SSH config file instead of applying a patch? |
|
You can also, in order to avoid edge effect disable algorithms for all connections use that : |
Tried to use ncclient package in python to establish a netconf connection with IOS XR programmability sandbox. faced couple of issues with respect to RSA algoritm selection on ncclient and not able to establish connection. Applied the patch provided to paramiko package in this link : paramiko/paramiko#1961 to resolve it. Enabled logging in code and debugged the above problem. Also, was able to connect to the device with ssh cli command and able to see the hello messages in ssh cli. Still facing below bad authentication type error when trying to run the program, need to investigate and fix the same to run the application and establish a connection with device. DEBUG:ncclient.transport.ssh:Authentication type (publickey) not permitted. DEBUG:ncclient.transport.ssh:Allowed methods: ['keyboard-interactive', 'password'] DEBUG:ncclient.transport.ssh:[host sandbox-iosxr-1.cisco.com session 0x7fa398c863a0] Bad authentication type; allowed types: ['keyboard-interactive', 'password']
This was found in the OpenStack CI which uses Cirros as a small cloud image for testing purposes. Cirros runs dropbear as ssh server. There a no issues connecting with paramiko < 2.9, with the latest versions, authentication with an RSA key is failing, while using an ECDSA key or password login still works. The failure looks like this, sadly I haven't found out yet how to gather more debugging about the connection process:
See also cirros-dev/cirros#74.
The text was updated successfully, but these errors were encountered: