doc: Remove all mentions of trust passwords

Closes lxc#147

Signed-off-by: Stéphane Graber <[email protected]>

doc/authentication.md

@@ -51,8 +51,8 @@ The workflow to authenticate with the server is similar to that of SSH, where an
 1. The server attempts to authenticate the client:
 
    - If the client certificate is in the server's trust store, the connection is granted.
-   - If the client certificate is not in the server's trust store, the server prompts the user for a token or the trust password.
-     If the provided token or trust password matches, the client certificate is added to the server's trust store and the connection is granted.
+   - If the client certificate is not in the server's trust store, the server prompts the user for a token.
+     If the provided token matches, the client certificate is added to the server's trust store and the connection is granted.
      Otherwise, the connection is rejected.
 
 To revoke trust to a client, remove its certificate from the server with [`incus config trust remove <fingerprint>`](incus_config_trust_remove.md).
@@ -73,10 +73,10 @@ To do so, copy the client certificate to the server and register it using [`incu
 (authentication-token)=
 #### Adding client certificates using tokens
 
-You can also add new clients by using tokens. This is a safer way than using the trust password, because tokens expire after a configurable time ({config:option}`server-core:core.remote_token_expiry`) or once they've been used.
+You can also add new clients by using tokens. Tokens expire after a configurable time ({config:option}`server-core:core.remote_token_expiry`) or once they've been used.
 
 To use this method, generate a token for each client by calling [`incus config trust add`](incus_config_trust_add.md), which will prompt for the client name.
-The clients can then add their certificates to the server's trust store by providing the generated token when prompted for the trust password.
+The clients can then add their certificates to the server's trust store by providing the generated token when prompted.
 
 <!-- Include start NAT authentication -->
 
@@ -85,8 +85,6 @@ If your Incus server is behind NAT, you must specify its external public address
 
     incus remote add <name> <IP_address>
 
-When you are prompted for the admin password, specify the generated token.
-
 When generating the token on the server, Incus includes a list of IP addresses that the client can use to access the server.
 However, if the server is behind NAT, these addresses might be local addresses that the client cannot connect to.
 In this case, you must specify the external address manually.

doc/howto/cluster_form.md

@@ -44,7 +44,6 @@ Would you like to use Incus clustering? (yes/no) [default=no]: yes
 What IP address or DNS name should be used to reach this server? [default=192.0.2.101]:
 Are you joining an existing cluster? (yes/no) [default=no]: no
 What member name should be used to identify this server in the cluster? [default=server1]:
-Setup password authentication on the cluster? (yes/no) [default=no]: no
 Do you want to configure a new local storage pool? (yes/no) [default=yes]:
 Name of the storage backend to use (btrfs, dir, lvm, zfs) [default=zfs]:
 Create a new ZFS pool? (yes/no) [default=yes]:
@@ -95,7 +94,7 @@ Basically, the initialization process consists of the following steps:
 
    `````{tabs}
 
-   ````{group-tab} Authentication tokens (recommended)
+   ````{group-tab} Authentication tokens
    If you configured your cluster to use {ref}`authentication tokens <authentication-token>`, you must generate a join token for each new member.
    To do so, run the following command on an existing cluster member (for example, the bootstrap server):
 
@@ -120,7 +119,7 @@ Basically, the initialization process consists of the following steps:
 
 `````{tabs}
 
-````{group-tab} Authentication tokens (recommended)
+````{group-tab} Authentication tokens
 
 ```{terminal}
 :input: sudo incus admin init
@@ -137,29 +136,6 @@ Choose "zfs.pool_name" property for storage pool "local":
 Would you like a YAML "incus admin init" preseed to be printed? (yes/no) [default=no]:
 ```
 
-````
-````{group-tab} Trust password
-
-```{terminal}
-:input: sudo incus admin init
-
-Would you like to use Incus clustering? (yes/no) [default=no]: yes
-What IP address or DNS name should be used to reach this server? [default=192.0.2.102]:
-Are you joining an existing cluster? (yes/no) [default=no]: yes
-Do you have a join token? (yes/no/[token]) [default=no]: no
-What member name should be used to identify this server in the cluster? [default=server2]:
-IP address or FQDN of an existing cluster member (may include port): 192.0.2.101:8443
-Cluster fingerprint: 2915dafdf5c159681a9086f732644fb70680533b0fb9005b8c6e9bca51533113
-You can validate this fingerprint by running "incus info" locally on an existing cluster member.
-Is this the correct fingerprint? (yes/no/[fingerprint]) [default=no]: yes
-Cluster trust password:
-All existing data is lost when joining a cluster, continue? (yes/no) [default=no] yes
-Choose "size" property for storage pool "local":
-Choose "source" property for storage pool "local":
-Choose "zfs.pool_name" property for storage pool "local":
-Would you like a YAML "incus admin init" preseed to be printed? (yes/no) [default=no]:
-```
-
 ````
 `````
 
@@ -184,7 +160,7 @@ You need a different preseed file for every server.
 
 `````{tabs}
 
-````{group-tab} Authentication tokens (recommended)
+````{group-tab} Authentication tokens
 To enable clustering, the preseed file for the bootstrap server must contain the following fields:
 
 ```yaml
@@ -236,7 +212,7 @@ The preseed files for new cluster members require only a `cluster` section with
 
 `````{tabs}
 
-````{group-tab} Authentication tokens (recommended)
+````{group-tab} Authentication tokens
 The preseed file for additional servers must include the following fields:
 
 ```yaml

doc/howto/images_remote.md

@@ -51,7 +51,7 @@ For example, enter the following command to add a remote through an IP address:
 
     incus remote add my-remote 192.0.2.10
 
-You are prompted to confirm the remote server fingerprint and then asked for the password or token, depending on the authentication method used by the remote.
+You are prompted to confirm the remote server fingerprint and then asked for the token.
 <!-- Include end add remotes -->
 
 ## Reference an image

doc/howto/initialize.md

@@ -49,7 +49,7 @@ Remote access (see {ref}`security_remote_access` and {ref}`authentication`)
   The default answer is `no`, which means remote access is not allowed.
   If you answer `yes`, you can connect to the server over the network.
 
-  You can choose to add client certificates to the server (manually or through tokens, the recommended way) or set a trust password.
+  You can choose to add client certificates to the server (manually or through tokens).
 
 Automatic image update (see {ref}`about-images`)
 : You can download images from image servers.

doc/howto/projects_confine.md

@@ -12,7 +12,6 @@ You can confine access to specific projects by restricting the TLS client certif
 See {ref}`authentication-tls-certs` for detailed information.
 
 To confine the access from the time the client certificate is added, you must either use token authentication or add the client certificate to the server directly.
-If you use password authentication, you can restrict the client certificate only after it has been added.
 
 Use the following command to add a restricted client certificate:
 
@@ -33,7 +32,7 @@ Use the following command to add a restricted client certificate:
 
 The client can then add the server as a remote in the usual way ([`incus remote add <server_name> <token>`](incus_remote_add.md) or [`incus remote add <server_name> <server_address>`](incus_remote_add.md)) and can only access the project or projects that have been specified.
 
-To confine access for an existing certificate (either because the access restrictions change or because the certificate was added with a trust password), use the following command:
+To confine access for an existing certificate, use the following command:
 
     incus config trust edit <fingerprint>