ploxiln/fab-classic

Public key authentication fails with Ubuntu 22.04 LTS servers

Closed this issue · 4 comments

Steps to replicate:

  1. Create a virtual server running Ubuntu 22.04 LTS and configure with an appropriate keypair (I have replicated this on instances running on both DigitalOcean and AWS)
  2. Create a minimal fabfile:
    from fabric.api import env, run, task
    
    env.host_string = "X.X.X.X"  # replace with IP address of your instance
    env.user = "myuser"  # replace with the username on the instance
    
    @task
    def hello():
        run("echo hello")
  3. Execute fab hello

Expected result:

The instance executes the hello command on the remote server and then disconnects

Actual result:

Authentication fails and the user is prompted to enter a password

➜ ~ fab hello
[X.X.X.X] run: echo hello
Connect error: Authentication failed.
[X.X.X.X] Login password for 'myuser': 

If I follow these same steps, but instead try it on a Ubuntu 20.04 LTS server it works correctly. I haven't tried this with any non-LTS releases.

Versions:

Local machine:

➜ ~ fab --version
fab-classic 1.19.2
paramiko-ng 2.8.10
Python 3.11.4

I get the same result with other versions of Python too (e.g. 3.8.x).

Remote machine:

myuser@X.X.X.X:~# ssh -V
OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022

Some extra info after further testing.

I tried this with upstream paramiko (by using the PARAMIKO_REPLACE=1 setting, to get the following versions

~ fab --version
fab-classic 1.19.2
Paramiko 3.2.0
Python 3.11.4

With upstream paramiko, it works correctly, giving the expected result:

➜ ~ fab hello
[X.X.X.X] run: echo hello
[X.X.X.X] out: hello
[X.X.X.X] out: 


Done.
Disconnecting from X.X.X.X ... done.

In working this out I also discovered that this was already reported in ploxiln/paramiko-ng#130 🤦‍♂️

Whilst this workaround does give the desired behaviour, it's still a problem in the default out-of-the-box installation.

Yup, this is a paramiko-ng issue.

The work-around, if not just use upstream paramiko instead, is to use a different key type, like ed25519 or ecdsa.

Yup, this is a paramiko-ng issue.

The work-around, if not just use upstream paramiko instead

That's what we've had to do in our code, but it's not ideal as the PARAMIKO_REPLACE=1 trick doesn't play nicely with requirements files

use a different key type, like ed25519 or ecdsa

This is a possibility, but the RSA is default key type in many SSH installs, so does represent a slight inconvenience in set up.

I guess the long-term "fix" is deciding whether paramiko-ng should still be the default at this point now that paramiko has become more active, but that's a decision for a separate issue.

yakky commented

Same issue here. Any reason to prefer paramiko-ng to paramiko?
environment variable trick does not work with tools like poetry, pip-tools, pipenv making really hard to use this package