Created attachment 1970842 [details] the podman buildfile Description of problem: When connecting to an ssh server which 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: --%snip%-- File "/usr/lib/python3.9/site-packages/paramiko/client.py", line 421, in connect t.start_client(timeout=timeout) File "/usr/lib/python3.9/site-packages/paramiko/transport.py", line 699, in start_client raise e File "/usr/lib/python3.9/site-packages/paramiko/transport.py", line 2130, in run self.kex_engine.parse_next(ptype, m) File "/usr/lib/python3.9/site-packages/paramiko/kex_curve25519.py", line 64, in parse_next return self._parse_kexecdh_reply(m) File "/usr/lib/python3.9/site-packages/paramiko/kex_curve25519.py", line 130, in _parse_kexecdh_reply self.transport._verify_key(peer_host_key_bytes, sig) File "/usr/lib/python3.9/site-packages/paramiko/transport.py", line 1941, in _verify_key if not key.verify_ssh_sig(self.H, Message(sig)): File "/usr/lib/python3.9/site-packages/paramiko/rsakey.py", line 152, in verify_ssh_sig key.verify( File "/usr/lib64/python3.9/site-packages/cryptography/hazmat/backends/openssl/rsa.py", line 571, in verify return _rsa_sig_verify( File "/usr/lib64/python3.9/site-packages/cryptography/hazmat/backends/openssl/rsa.py", line 270, in _rsa_sig_verify pkey_ctx = _rsa_sig_setup( File "/usr/lib64/python3.9/site-packages/cryptography/hazmat/backends/openssl/rsa.py", line 213, in _rsa_sig_setup raise UnsupportedAlgorithm( cryptography.exceptions.UnsupportedAlgorithm: sha1 is not supported by this backend for RSA signing. --%snip%-- Version-Release number of selected component (if applicable): 2.12.0-1.el9 How reproducible: always Steps to Reproduce: 1. setup an ssh server with an rsa host key 2. clear this host key from any known_hosts files 3. connect twice Actual results: the first connect succeeds, the second connect fails with the trace above. Expected results: both connects successful Additional info: I attached two files to reproduce this behaviour easily. The python script connects to the ssh daemon running in a container via port 22022, logs in using a provided ssh key pair and calls "whoami". Since the script does not load any keys in advance, the rsa host key is unknown at first. Since we're using "AutoAddPolicy" the host key is known when attempting to connect the second time. podman build -t sshrsa:latest Buildfile-sshrsa podman run --rm -d -p 22022:22 sshrsa:latest ./paramikotest.py
Created attachment 1970843 [details] the example python script
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
I raised this issue upstream: https://github.com/paramiko/paramiko/issues/2259
Upstream's comment: 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 `cryptography`? 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 `skip_host_key_verification` boolean or something. What do you think?
Of course the best solution is to upgrade the server, but sometimes this isn't a valid option. Either because the server is a proprietary blackbox or it must be kept at a specific stable version, or, simply because noone cared to provide an update to the software to support other algorithms yet. In my case it's about jenkins, it seems only to support rsa sha1 hostkeys for the ssh configuration interface. Sure, I'm fine with a "skip_host_key_verification" flag if this covers outdated algorithms as well (and not only stuff like mismatching fingerprints). Thanks!
I'm working on "skip_host_key_verification" flag implementation for upstream to consider (I have an implementation but want to add some tests for it yet). However, whilst I was working on that it occurred to me that you could work around the issue you're having by adding: ssh._host_keys.clear() before the ssh.connect(... That's using a private interface but it's better than nothing at the moment I guess.
Great, thanks a lot!