Invalid Key Error on Paramiko 2.7.1

[apldev3]

I recently updated my project's Paramiko version to the latest due to our use of OpenSSH formatted keys. Unfortunately, on 2.7.1 I get an error of Invalid Key, which is being thrown by ed25519key.py. This seems a bit strange as we're only using RSA at the moment, which would probably explain why it's complaining, but I'm not sure why it's not routing to rsakey.py.

Using the SSH key via the usual ssh -i command works, so that lends credence to it being a valid key. We also have a Feature Flag that gets set based on whether or not PyCryptodome can parse it as a valid RSA Private key successfully, which it does. With that, there are two votes in favor of this being a valid RSA Private key.

I attempted to rollback to Paramiko 2.7.0, but that seems to cause SSHClient.connect to get caught in an infinite loop as the call never returns (at least it hadn't for ~5 minutes before I killed the process).

This is the call being used:

ssh_client.connect(
                        hostname=client.host,
                        port=client.port,
                        key_filename=key_file,
                        look_for_keys=False,
                    )

Quick aside look_for_keys is set to False as I was falling victim to #1390 or something similar. I got past that with look_for_keys=False, which is fine as we specify the key to use explicitly anyway.

For those interested here's the Stacktrace:

Traceback (most recent call last):
  File "/home/quicksilver/projects/swingshift/swsh/operation_files/utils/decorators.py", line 55, in decorated
    response = func(*args, **kwargs)
  File "/home/quicksilver/projects/swingshift/swsh/operation_files/assert_reachable_from_client.py", line 65, in reachable_from_client
    with self.get_ssh_client(result_client_execution.client) as ssh_client:
  File "/home/quicksilver/.pyenv/versions/3.7.6/lib/python3.7/contextlib.py", line 112, in __enter__
    return next(self.gen)
  File "/home/quicksilver/projects/swingshift/swsh/operation_files/sessionwrapper.py", line 96, in get_ssh_client
    look_for_keys=False,
  File "/home/quicksilver/.pyenv/versions/swsh-venv/lib/python3.7/site-packages/paramiko/client.py", line 446, in connect
    passphrase,
  File "/home/quicksilver/.pyenv/versions/swsh-venv/lib/python3.7/site-packages/paramiko/client.py", line 764, in _auth
    raise saved_exception
  File "/home/quicksilver/.pyenv/versions/swsh-venv/lib/python3.7/site-packages/paramiko/client.py", line 677, in _auth
    key_filename, pkey_class, passphrase
  File "/home/quicksilver/.pyenv/versions/swsh-venv/lib/python3.7/site-packages/paramiko/client.py", line 586, in _key_from_filepath
    key = klass.from_private_key_file(key_path, password)
  File "/home/quicksilver/.pyenv/versions/swsh-venv/lib/python3.7/site-packages/paramiko/pkey.py", line 235, in from_private_key_file
    key = cls(filename=filename, password=password)
  File "/home/quicksilver/.pyenv/versions/swsh-venv/lib/python3.7/site-packages/paramiko/ed25519key.py", line 63, in __init__
    signing_key = self._parse_signing_key_data(data, password)
  File "/home/quicksilver/.pyenv/versions/swsh-venv/lib/python3.7/site-packages/paramiko/ed25519key.py", line 112, in _parse_signing_key_data
    raise SSHException("Invalid key")
paramiko.ssh_exception.SSHException: Invalid key

Anyone have any suggestions?

[ploxiln]

Paramiko SSHClient attempts all key types for a key file, one at a time. Ed25519Key is the last one it attempts. So you're not seeing the real error when the ssh client attempts to load your key file as an RSAKey, that happened earlier and failed for some reason. You could try just pkey = RSAKey.from_private_key_file(key_file) to get a more relevant error/backtrace.

[apldev3]

That's definitely interesting. Per your suggestion, I tried RSAKey.from_private_key_file(key_file) and it loads the key just fine.

I can then pass that as the pkey param to connect and that error doesn't occur.

Any thoughts on how to prevent having to create the key manually? I'd prefer not to have to try all the key types ourself when Paramiko has the logic built in to do so.

Unrelated, pretty sure I've now also bumped into: #515