Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: allow passing preferred_rsa_keys to account for the presence of etherogeneous SSH servers #2049

Closed
nemesifier opened this issue May 11, 2022 · 1 comment

Comments

@nemesifier
Copy link

Follow up of #1961.

Let's consider the following situation.

A system like OpenWISP can manage an etherogeneous network of OpenWrt routers running both newer and older versions of dropbear.
SSH connections via paramiko to newer versions of dropbear will work.
SSH connections via paramiko to older versions of dropbear will not work.

We can apply the fix disabled_algorithms=dict(pubkeys=["rsa-sha2-512", "rsa-sha2-256"]),, but wouldn't that mean that on new version of dropbear we'd be using the old sha1?

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 = [
"rsa-sha2-512",
"rsa-sha2-256",
"ssh-rsa",
]

if isinstance(hostkey, RSAKey):
    self._preferred_keys = self.preferred_rsa_keys

And allow us to pass a list of preferred_rsa_keys which is backward compatible with old systems.

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.

@bitprophet
Copy link
Member

Rolling into #2054!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants