The aim is to maintain functional parity between the classic juju 2.9 CLI and the new strictly confined juju 3.0 CLI.
The main use cases:
- juju CLI ssh and scp operations on machines provisioned by juju
- juju CLI ssh access to existing machines managed by the user to manually enroll them
Under the covers juju uses the Go SSH client APIs
Case 1 covers Juju CLI commands like
juju ssh and
juju scp as well as
When juju provisions a machine, it adds the user’s public key to the authorised keys list on the provisioned machine to allow subsequent ssh access via the Juju CLI.
Case 2 is for the
juju add-machine command where the user wants to take an existing machine and add it to the juju model - juju needs to add provisioning scripts to the machine. The user will already have ssh access to the machine.
juju add-machine command does have a
--private-key option where you can use a private key located elsewhere, but with the strict snap, the user would be forced to copy their private key to somewhere under $home that the snap could access, which is not ideal.