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 golang.org/x/crypto/ssh
.
Case 1 covers Juju CLI commands like juju ssh
and juju scp
as well as juju exec
.
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.
The 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.