Users and roles settings

```bash
$ base32 -w32 < /dev/urandom | head -1
```

This command will produce a base32-encoded secret that can be added to the secret field in users.xml.

To enable TOTP for a specific user, add to any existing password-based field (like `password` or `password_sha256_hex`) another `time_based_one_time_password` section.

The [qrencode](https://linux.die.net/man/1/qrencode) tool can be used to generate a QR code for the TOTP secret.

```
$ qrencode -t ansiutf8 'otpauth://totp/ClickHouse?issuer=ClickHouse&secret=JBSWY3DPEHPK3PXP'
```

After configuring TOTP for a user, one-time password can be used as a part of the authentication process as described above.

### username/ssh-key[​](#user-sshkey "Direct link to username/ssh-key")

This setting allows authenticating with SSH keys.

Given a SSH key (as generated by `ssh-keygen`) like

```
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDNf0r6vRl24Ix3tv2IgPmNPO2ATa2krvt80DdcTatLj [email protected]
```

The `ssh_key` element is expected to be

```
<ssh_key>
     <type>ssh-ed25519</type>
     <base64_key>AAAAC3NzaC1lZDI1NTE5AAAAIDNf0r6vRl24Ix3tv2IgPmNPO2ATa2krvt80DdcTatLj</base64_key>
 </ssh_key>
```

Substitute `ssh-ed25519` with `ssh-rsa` or `ecdsa-sha2-nistp256` for the other supported algorithms.

### Multiple Authentication Methods[​](#multiple-authentication-methods "Direct link to Multiple Authentication Methods")

A single user can be configured with multiple authentication methods using the `<auth_methods>` element. This allows a user to authenticate with any one of the listed methods — for example, a user could have both a password and an LDAP credential, and logging in with either one would succeed.

Each child element of `<auth_methods>` is an arbitrarily-named wrapper that contains exactly one authentication type. The wrapper name (e.g. `<method1>`, `<primary>`, `<a1>`) does not matter; only the inner authentication element is used.

**Example: multiple passwords**

```
<users>
    <my_user>
        <auth_methods>
            <primary>
                <password>password_one</password>
            </primary>
            <secondary>
                <password_sha256_hex>65e84be33532fb784c48129675f9eff3a682b27168c0ea744b2cf58ee02337c5</password_sha256_hex>
            </secondary>
        </auth_methods>
    </my_user>
</users>
```

**Example: mixed authentication types**

```
<users>
    <my_user>
        <auth_methods>
            <a1>
                <password>plaintext_pass</password>
            </a1>
            <a2>
                <password_sha256_hex>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855</password_sha256_hex>
            </a2>
            <a3>
                <ldap>
                    <server>my_ldap_server</server>
                </ldap>
            </a3>
        </auth_methods>
    </my_user>
</users>
```

The following authentication types are supported inside `<auth_methods>`:

- **`password`** — plaintext password
- **`password_sha256_hex`** — SHA256 password hash
- **`password_scram_sha256_hex`** — SCRAM-SHA-256 password hash
- **`password_double_sha1_hex`** — double SHA1 password hash
- **`ldap`** — LDAP server authentication
- **`kerberos`** — Kerberos authentication
- **`ssl_certificates`** — SSL certificate authentication
- **`ssh_keys`** — SSH key authentication
- **`http_authentication`** — HTTP authentication

**Rules and restrictions:**

- `<auth_methods>` **cannot** be used together with authentication methods specified at the user level. Use one style or the other, not both.
- `<auth_methods>` must contain at least one authentication method.
- Each wrapper element inside `<auth_methods>` must contain exactly one authentication type (with the exception of `<ssh_keys>`, which can contain multiple, for backwards compatibility).
- TOTP (`<time_based_one_time_password>`) is specified at the user level (outside `<auth_methods>`) and applies to all password-based methods in the list. At least one password-based method is required when TOTP is enabled.

**Example: `auth_methods` with TOTP**

```
<users>
    <my_user>
        <auth_methods>
            <a1>
                <password>my_password</password>
            </a1>
            <a2>
                <ldap>
                    <server>ldap_server_1</server>
                </ldap>
            </a2>
        </auth_methods>
        <time_based_one_time_password>
            <secret>JBSWY3DPEHPK3PXP</secret>
        </time_based_one_time_password>
    </my_user>
</users>
```

In this example, TOTP verification is applied to the password-based method (`<password>`), while the LDAP method authenticates against the external server independently.

### access\_management[​](#access_management-user-setting "Direct link to access_management")

This setting enables or disables using of SQL-driven [access control and account management](/docs/operations/access-rights#access-control-usage) for the user.

Possible values:

- 0 — Disabled.
- 1 — Enabled.

Default value: 0.

### grants[​](#grants-user-setting "Direct link to grants")

This setting allows to grant any rights to selected user.
Each element of the list should be `GRANT` query without any grantees specified.

Example:

```
<user1>
    <grants>
        <query>GRANT SHOW ON *.*</query>
        <query>GRANT CREATE ON *.* WITH GRANT OPTION</query>
        <query>GRANT SELECT ON system.*</query>
    </grants>
</user1>
```

This setting can't be specified at the same time with
`dictionaries`, `access_management`, `named_collection_control`, `show_named_collections_secrets`
and `allow_databases` settings.

### user\_name/networks[​](#user-namenetworks "Direct link to user_name/networks")

List of networks from which the user can connect to the ClickHouse server.

Each element of the list can have one of the following forms:

- `<ip>` — IP address or network mask.

  Examples: `213.180.204.3`, `10.0.0.1/8`, `10.0.0.1/255.255.255.0`, `2a02:6b8::3`, `2a02:6b8::3/64`, `2a02:6b8::3/ffff:ffff:ffff:ffff::`.
- `<host>` — Hostname.

  Example: `example01.host.ru`.

  To check access, a DNS query is performed, and all returned IP addresses are compared to the peer address.
- `<host_regexp>` — Regular expression for hostnames.

  Example, `^example\d\d-\d\d-\d\.host\.ru$`

  To check access, a [DNS PTR query](https://en.wikipedia.org/wiki/Reverse_DNS_lookup) is performed for the peer address and then the specified regexp is applied. Then, another DNS query is performed for the results of the PTR query and all the received addresses are compared to the peer address. We strongly recommend that regexp ends with $.

All results of DNS requests are cached until the server restarts.

**Examples**

To open access for user from any network, specify:

```
<ip>::/0</ip>
```

Note

It's insecure to open access from any network unless you have a firewall properly configured or the server is not directly connected to Internet.

To open access only from localhost, specify:

```
<ip>::1</ip>
<ip>127.0.0.1</ip>
```

### user\_name/profile[​](#user-nameprofile "Direct link to user_name/profile")

You can assign a settings profile for the user. Settings profiles are configured in a separate section of the `users.xml` file. For more information, see [Profiles of Settings](/docs/operations/settings/settings-profiles).

### user\_name/quota[​](#user-namequota "Direct link to user_name/quota")

Quotas allow you to track or limit resource usage over a period of time. Quotas are configured in the `quotas`
section of the `users.xml` configuration file.

You can assign a quotas set for the user. For a detailed description of quotas configuration, see [Quotas](/docs/operations/quotas).

### user\_name/databases[​](#user-namedatabases "Direct link to user_name/databases")

In this section, you can limit rows that are returned by ClickHouse for `SELECT` queries made by the current user, thus implementing basic row-level security.

**Example**

The following configuration forces that user `user1` can only see the rows of `table1` as the result of `SELECT` queries, where the value of the `id` field is 1000.