error: "sha1 is not supported by this backend for RSA signing" #2259
Comments
|
Thanks for transferring this report over here, we never would have seen it otherwise. If I understand correctly what's going on, this error occurs because a server is crafting its host keys with an obsolete, insecure hashing algorithm, in SHA1. Isn't.... the best solution here to upgrade the server so that it can use a modern, secure algorithm? Instead of changing paramiko to blithely ignore a security-relevant error raised out of I recognize that a server host key isn't on the same level of importance as an SSL key pair, since server host keys aren't usually backed by third-party CA certs and such, but this seems like an imprudent way to handle the situation. Rather than accepting this connection by default and warning about an obsolete key being ignored, it seems to me a better solution would be an 'opt in' flag that a user would have to specify... a What do you think? |
|
@bskinn, I've updated the bugzilla ticket with your comment so we can get the original reporter's response. I personally would be happy enough with an option to ignore this issue. Regarding updating the server, that may be very tricky in some cases, such as for an embedded device with a server that doesn't support anything more modern in terms of key algorithms. |
Great, thanks!
👍, it seems to me that's the best approach for the 2.x maintenance line. We'd welcome a PR from anyone interested in working on it. Do you know, would the new experimental auth strategy features allow user-side handling of this hitch? (3.2 CHANGELOG, scroll down to the first red callout.) One of the big goals of that new machinery (including some as-yet-unimplemented pieces) is to allow users to cope with their hardware weirdness themselves, instead of fixes needed upstream. We'd also welcome help here, again from anyone interested, testing those new experimental features to see if they can resolve this.
I know, cognitively, that this is a problem, but I've never dealt with it myself and so I keep forgetting to consider it. Can you help me out by providing some concrete examples of embedded devices like this? Control hardware for chemical process industry? Manufacturing equipment? IoT? Controllers in cars? The specificity will help the category stick in mind. |
I don't have anything that I use paramiko with. However, I have a couple of Ubiquity WiFi access points (which get regular updates by the way, unusual for this sort of device I think) and I can access them via openssh but I need entries like these in my |
|
Feedback from reporter:
|
|
Ok, sounds like a 'skip' option would be viable for everyone in the conversation here. And yes, I would expect a skip flag would skip the verification entirely. Certainly that's the first implementation I'd recommend, and we would consider more granular skip-or-not controls once we determined they're not YAGNI. I'm going to flag this for bitprophet to review at whatever point in the future he does a pass on the flag, so he can weigh in. But, I'm confident enough in the feature to request anyone interested prepare a PR to implement this. |
|
@gubenkoved -- I think you're looking at the wrong part of the codebase.
The issue here is host validation -- confirming to the client that the server is who they are expecting to be connecting to. Also, if the underlying |
|
Thank you for your answer, @bskinn! I've removed my comment before you replied as I realised sources of my own confusion here. In my particular case I was able to work around this issue supplying Additionally, I beleive similar issue can appear for the "client authentication" part of the paramiko as well. Here is the sample traceback. I also want to mention FIPS OpenSSL provider as a reason of SHA1 not being available as RSA digest algorithm in my case. |
Adds _skip_host_key_verification attribute to Transport and provides a set_skip_host_key_verification method to set or clear it (default: `False`). Adds skip_host_key_verification parameter to SSHClient.connect (default: `False`), which is passed directly to the transport. Skipping host key verification might be useful in very rare cases where it is not possible to verify the target's key, for example if it uses a legacy signature algorithm that is no longer supported by the client, e.g. in paramiko#2259.
Adds _skip_host_key_verification attribute to Transport and provides a set_skip_host_key_verification method to set or clear it (default: `False`). Adds skip_host_key_verification parameter to SSHClient.connect (default: `False`), which is passed directly to the transport. Skipping host key verification might be useful in very rare cases where it is not possible to verify the target's key, for example if it uses a legacy signature algorithm that is no longer supported by the client, e.g. in paramiko#2259.
This issue was originally reported in Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2214984
When connecting to an ssh server that provides an rsa host key and the host key is known (either by a known_hosts file or by previous connection attempts), paramiko fails with "cryptography.exceptions.UnsupportedAlgorithm: sha1 is not supported by this backend for RSA signing", giving the following traceback:
This is with paramiko 2.12.0 on Red Hat Enterprise Linux 9 (or a clone thereof), where sha1 is not supported for cryptographic operations.
Steps to Reproduce:
Actual results:
the first connect succeeds, the second connect fails with the trace above.
Expected results:
both connects successful
The original reporter provided a couple of attachments to help reproduce this issue, running an ssh server in a container. I can attach those and the accompanying instructions here if it's helpful.
My initial thought is that paramiko should trap this exception and treat the case the same as if the host key was not found, possibly providing some warning that that had happened so that users would understand why an existing key was ignored.
The text was updated successfully, but these errors were encountered: