Juju SSH doesn't attempt to use ED25519 keys

[James Simpson]

While Juju is able to make use of ED25519 keys for SSH, it doesn't try to use them by default.

I've been able to add an ED25519 public key to a model:

stg-terraform-test@server:~$ ssh-keygen -E md5 -lf .ssh/id_ed25519
256 MD5:8b:b5:49:ff:83:3f:9d:0e:b4:a9:a2:d7:6d:b6:cc:f8 .ssh/id_ed25519.pub (ED25519)
stg-terraform-test@server:~$ juju list-ssh-keys
Keys used in model: admin/stg-terraform-test
8b:b5:49:ff:83:3f:9d:0e:b4:a9:a2:d7:6d:b6:cc:f8 (stg-terraform-test@server)

I can use that key to SSH manually to a juju-deployed machine:
stg-terraform-test@server:~$ ssh ubuntu@10.132.51.4
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-139-generic x86_64)

However, Juju SSH doesn't work as the key is never tried:
stg-terraform-test@server:~$ juju ssh 4
stg-terraform-test@10.132.51.4: Permission denied (publickey).

I can trick Juju into working by copying or linking the ED25519 key as "id_rsa":
stg-terraform-test@server:~$ ln -s id_ed25519 .ssh/id_rsa
stg-terraform-test@server:~$ juju ssh 4
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-139-generic x86_64)

Or of course by specifying the key ("juju ssh 4 -i .ssh/id_ed25519").

-------

It may be determined that this bug is a duplicate of #1901923, but it is unclear to me from reading the info in that bug and from reading the Juju documentation what exactly "supported" means in this situation.

This appears to be intended behaviour rather than a bug, as the comment here (https://github.com/juju/juju/blob/16b3daad4d003ebf4990d464f3cedf1f5d3b7cfd/cmd/juju/ssh/ssh.go#L59) states "The default identity known to Juju and used by this command is ~/.ssh/id_rsa".

Is there a way to change this default? Or for Juju to try keys other than "id_rsa"?

Thanks!

[Juan M. Tirado (tiradojm)]

Juju only works with keys stored as "id_dsa.pub", "id_rsa.pub", "identity.pub". Unfortunately, this is not documented anywhere. See the corresponding code here https://github.com/juju/juju/blob/develop/cmd/juju/common/authkeys.go#L87

Could you please retry with the aforementioned filenames?

[Haw Loeung (hloeung)]

"authkeys.go" should really be updated to *not* use id_dsa.pub (old DSA algorithm that's disabled in OpenSSH by default[1]) and include ed25519.

There should also be a preference order too.

[1]http://www.openssh.com/legacy.html

[Tom Haddon (mthaddon)]

We have a workaround for this (symlinking the key to one of the ones you support). This bug is more about supporting this properly.

[Jack Shaw (jack-shaw)]

Hi,

what version of Juju are you using?

I have not been able to replicate this bug in 3.1
```
juju bootstrap aws/eu-west-2 aws
juju add-model
juju add-ssh-key "$(cat ~/.ssh/id_ed25519.pub)"
juju add-machine
juju ssh 0
```
This is able to successfully connect to the machine

I have verified this is using my edwards curve key by removing the client key from the machine's authorized_keys file

On a side-note, I believe `authkeys.go` mentioned above is a red herring. It's used to set `authorized-keys` model config item, which I have verified the above steps correctly pick up my ed25519 key.

This is because `juju add-ssh-key` and `juju import-ssh-key` themselves manipulate this hidden model config item (which it seems you must have run for the ed25519 key to appear in `list-ssh-keys`?)

However, it is weird that we still add only id_dsa.pub and id_rsa.pub by default. I agree that we should add ed25519 and ecdsa keys ASAP and remove dsa keys when we can

The way juju handles ssh keys for the most part 10 year old code. Imo the whole thing needs a re-write

[Jack Shaw (jack-shaw)]

https://github.com/juju/juju/pull/15736