Controller logins

When a Juju user logs in to a controller there are two basic scenarios:

  • Logging in during user initialisation
  • Logging in with an existing user

Each of these are described in greater detail on this page.

Terminology: A known controller is one that the local Juju client is aware of. It shows up in the output for the controllers command and has its metadata recorded in ~/.local/share/juju/controllers.yaml.

Logging in during user initialisation

This scenario covers the case where a Juju user has never logged in to a controller. Doing so for the first time initialises the user, which involves, in particular, the creation of a password on the part of the operator. There are two sub-cases:

  • Using the initial user token
  • Using a re-generated user token

Doing either results in the controller becoming known to the client.

Using the initial user token

This is the “normal” way for initialising a user.

When a Juju user is added to a controller with the add-user command a token is printed. This is provided to the person who will interact with Juju as that user. This token is then supplied to the register command to register, and log in to, the controller:

juju register MHMTBHdpbGwUNTQuMjI2LjI....MCoLdEXylP6MRWITCHNvbWUtYXdz

Sample output:

Enter a new password: *******
Confirm password: *******
Enter a name for this controller [some-aws]: that-aws
Initial password successfully set for will.

Welcome, will. You are now logged into "that-aws".

There are no models available. You can add models with
"juju add-model", or you can ask an administrator or owner
of a model to grant access to that model with "juju grant".

The end result is that the controller is now known to this client:

juju controllers

Output:

Use --refresh option with this command to see the latest information.

Controller  Model  User  Access  Cloud/Region  Models  Nodes  HA  Version
that-aws*   -      will  login                      -      -   -  2.6-beta2

Using a re-generated user token

There are some valid situations where a registration token may need to be re-generated for a Juju user:

  • A login is desired from multiple clients.
  • The original token was simply misplaced.

The end result is the same as in the first scenario. A new user will be initialised.

This is done with the change-user-password command:

juju change-user-password --reset fred

Sample output:

Password for "fred" has been reset.
Ask the user to run:
     juju register MHMTBHdpbGwwPxMUNQuMjI2LjI....IuMTonqYile1dhwTCHNvbWUtYXdz

Any previously generated token for user ‘fred’ is automatically invalidated.

Logging in with an existing user

This scenario covers the case where a Juju user has already logged in to the controller at least once from any device. Here, Juju is expecting a specific password for authentication to succeed. There are two sub-cases:

  • Referencing a known controller by name
  • Referencing an unknown controller by API endpoint

The API method results in the controller becoming known to the client.

Referencing a known controller by name

This is the “normal” way for logging in to a controller:

juju login -c this-aws

Output:

Enter username: mike

please enter password for mike on this-aws: *******
Welcome, mike. You are now logged into "this-aws".

There are no models available. You can add models with
"juju add-model", or you can ask an administrator or owner
of a model to grant access to that model with "juju grant".

The login command also accepts a username with the -u option.

Logging in to an unknown controller via an API endpoint

Beginning with v.2.6.0, a controller can be accessed via its API endpoint.

A few use cases for this feature:

  • A login is desired from multiple clients
  • A controller is migrated and Juju users need to reconnect

The controller’s CA certificate is used to identify the controller to the operator. A fingerprint of the certificate will be displayed and the operator will need to confirm that fingerprint before connecting.

If the controller is already known to the client then the command will print output guiding the operator to use the non-API method, and then exit.

Note: The endpoint method of logging in will only work if the controller itself is running v.2.6.0.

Example

The API endpoint can be obtained from the show-controller command on a client currently connected to the controller:

juju show-controller | grep endpoints

Sample output:

    api-endpoints: ['54.226.250.155:17070']

The fingerprint of the CA certificate can be found similarly:

juju show-controller | grep fingerprint

Sample output:

    ca-fingerprint: FA:B6:E3:E5:86:61:2F:D0:C8:45:DF:62:49:57:4C:78:BC:FE:83:79:29:71:49:E2:9E:D2:E2:18:2E:37:E9:EF

And now from a separate device:

juju login 54.226.250.155:17070 -c some-aws

The controller name is arbitrary, but hopefully meaningful, just like it is during the standard registration process.

Sample output:

Controller "54.226.250.155:17070" presented a CA cert that could not be verified.
CA fingerprint: [FA:B6:E3:E5:86:61:2F:D0:C8:45:DF:62:49:57:4C:78:BC:FE:83:79:29:71:49:E2:9E:D2:E2:18:2E:37:E9:EF]
Trust remote controller? (y/N): y

Enter username: admin

Enter password: *******

Welcome, admin. You are now logged into "some-aws".

There are 2 models available. Use "juju switch" to select
one of them:
  - juju switch controller
  - juju switch default

The end result is that the controller is now known to this client:

juju controllers

Output:

Use --refresh option with this command to see the latest information.

Controller  Model  User   Access     Cloud/Region  Models  Nodes    HA  Version
some-aws*   -      admin  superuser                     2      1  none  2.6-beta2

Last updated a month ago. Help improve this document in the forum.