Authenticating clients with the Multipass service

See also: authenticate, local.passphrase.

[since version 1.9.0]
Work in progress

Multipass requires clients to be authenticated with the service before allowing commands to complete. How this authentication is accomplished depends of few factors. This document will describe how authentication is handled depending on the host OS being used.

Contents:

Linux and macOS hosts

Linux and macOS hosts currently use a Unix domain socket for client and daemon communication. This socket only allows a client to connect via a user who belongs to the particular group the socket is owned by. For example, this group could be sudo, admin, or wheel and the user needs to belong to this group or else permission will be denied when connecting.

New methodology

With the authentication change, the socket will still be set as mentioned above until the first client connects at which point the socket will be open for all users to connect. This first client includes both the CLI and GUI, ie, tray, clients for the user. Any other user trying to connect to the Multipass service will need to authenticate with the service.

Windows hosts

The Windows host uses a TCP socket listening in port 50051 for client connections. This socket is open for all to use since there is no concept of file ownership for TCP sockets. This is not very secure in that any Multipass client can connect to the service and issue any commands.

New methodology

To close this gap, as previously mentioned, the client will now need to be authenticated with the Multipass service. To ease the burden of having to authenticate the client, the user who installs the updated version of Multipass will automatically have their clients authenticated with the service. Any other users connecting to the service will have to use authenticate.

Setting the passphrase

In order to authenticate, the client has to provide a preset password set by the administrator. This is currently achieved via a privileged multipass set local.passphrase command. A future revision of Multipass will relax the privileged part when setting the passphrase. However, the client setting the passphrase will need to already be authenticated.

In case client cannot authorize and the passphrase cannot be set

It is possible that another client that is privileged to connect to the Multipass socket will connect first and make it seemingly impossible to set the local.passphrase and also authorize the client with the service. One will see something like the following:

$ multipass list
list failed: The client is not authenticated with the Multipass service.
Please use 'multipass authenticate' before proceeding.
$ multipass authenticate
Please enter passphrase: 
authenticate failed: Passphrase is not set. Please `multipass set local.passphrase` with a trusted client.
$ multipass set local.passphrase
Please enter passphrase: 
Please re-enter passphrase: 
set failed: The client is not authenticated with the Multipass service.
Please use 'multipass authenticate' before proceeding.

and then it seems impossible to authorize the client to connect to the service. This may not even work when using sudo.

The following workaround should help get out of this situation:

$ cat ~/snap/multipass/current/data/multipass-client-certificate/multipass_cert.pem | sudo tee -a /var/snap/multipass/common/data/multipassd/authenticated-certs/multipass_client_certs.pem > /dev/null
$ snap restart multipass

At this point, your client should be authenticated with the Multipass service.


Last updated a day ago.