Note: YUBICO_CLIENT_ID, YUBICO_SECRET_KEY, and ADMIN_TOKEN are provided in my .env file.
Steps to reproduce
Start the server with docker-compose up.
Log in using the web app, and add your Yubikey OTP as your two-step authentication.
Stop and remove the docker containers using docker-compose down.
Re-create and start the docker containers using docker-compose up.
Try to login and use your Yubikey OTP as two-step authentication.
Expected behaviour
I should be able to log in with the Yubikey OTP I set up before.
Actual behaviour
The web app says "Given Yubikey is not registered" when I try to use the Yubikey OTP as two-step authentication.
Troubleshooting data
When I try to log into the newly created container, I get the following error:
bitwarden_1 | [2022-04-03 09:07:25.072][request][INFO] POST /identity/connect/token
bitwarden_1 | [2022-04-03 09:07:25.092][vaultwarden::api::core::two_factor::yubikey][ERROR] Given Yubikey is not registered
bitwarden_1 | [2022-04-03 09:07:25.092][response][INFO] POST /identity/connect/token (login) => 400 Bad Request
Originally created by @mtnakayama on GitHub (Apr 3, 2022).
<!--
# ###
NOTE: Please update to the latest version of vaultwarden before reporting an issue!
This saves you and us a lot of time and troubleshooting.
See:
* https://github.com/dani-garcia/vaultwarden/issues/1180
* https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image
# ###
-->
<!--
Please fill out the following template to make solving your problem easier and faster for us.
This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them.
Remember to hide/redact personal or confidential information,
such as passwords, IP addresses, and DNS names as appropriate.
-->
### Yubikey OTP not persistent after re-creating Docker container
Yubikey OTP is not persistent when destroying and re-creating a vaultwarden docker container, even when the `/data` volume is mounted.
### Deployment environment
### Your environment (Generated via diagnostics page)
* Vaultwarden version: v1.24.0
* Web-vault version: v2.25.1
* Running within Docker: true (Base: Debian)
* Environment settings overridden: true
* Uses a reverse proxy: true
* IP Header check: true (X-Real-IP)
* Internet access: true
* Internet access via a proxy: false
* DNS Check: true
* Time Check: true
* Domain Configuration Check: true
* HTTPS Check: true
* Database type: SQLite
* Database version: 3.35.4
* Clients used: Firefox 98.0.2 (64-bit) on Manjaro Linux
* Reverse proxy and version: nginx/1.20.2 (linuxserver/swag docker container)
* Other relevant information:
### Config (Generated via diagnostics page)
<details><summary>Show Running Config</summary>
**Environment settings which are overridden:** ADMIN_TOKEN, YUBICO_CLIENT_ID, YUBICO_SECRET_KEY
```json
{
"_duo_akey": null,
"_enable_duo": false,
"_enable_email_2fa": false,
"_enable_smtp": true,
"_enable_yubico": true,
"_ip_header_enabled": true,
"admin_ratelimit_max_burst": 3,
"admin_ratelimit_seconds": 300,
"admin_token": "***",
"allowed_iframe_ancestors": "",
"attachments_folder": "data/attachments",
"authenticator_disable_time_drift": false,
"data_folder": "data",
"database_max_conns": 10,
"database_url": "****/**.*******",
"db_connection_retries": 15,
"disable_2fa_remember": false,
"disable_admin_token": false,
"disable_icon_download": false,
"domain": "*****://*********.**************.***",
"domain_origin": "*****://*********.**************.***",
"domain_path": "",
"domain_set": true,
"duo_host": null,
"duo_ikey": null,
"duo_skey": null,
"email_attempts_limit": 3,
"email_expiration_time": 600,
"email_token_size": 6,
"emergency_access_allowed": true,
"emergency_notification_reminder_schedule": "0 5 * * * *",
"emergency_request_timeout_schedule": "0 5 * * * *",
"enable_db_wal": true,
"extended_logging": true,
"helo_name": null,
"hibp_api_key": null,
"icon_blacklist_non_global_ips": true,
"icon_blacklist_regex": null,
"icon_cache_folder": "data/icon_cache",
"icon_cache_negttl": 259200,
"icon_cache_ttl": 2592000,
"icon_download_timeout": 10,
"icon_redirect_code": 302,
"icon_service": "internal",
"incomplete_2fa_schedule": "30 * * * * *",
"incomplete_2fa_time_limit": 3,
"invitation_org_name": "Vaultwarden",
"invitations_allowed": true,
"ip_header": "X-Real-IP",
"job_poll_interval_ms": 30000,
"log_file": null,
"log_level": "Info",
"log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
"login_ratelimit_max_burst": 10,
"login_ratelimit_seconds": 60,
"org_attachment_limit": null,
"org_creation_users": "",
"password_iterations": 100000,
"reload_templates": false,
"require_device_email": false,
"rsa_key_filename": "data/rsa_key",
"send_purge_schedule": "0 5 * * * *",
"sends_allowed": true,
"sends_folder": "data/sends",
"show_password_hint": false,
"signups_allowed": false,
"signups_domains_whitelist": "",
"signups_verify": false,
"signups_verify_resend_limit": 6,
"signups_verify_resend_time": 3600,
"smtp_accept_invalid_certs": false,
"smtp_accept_invalid_hostnames": false,
"smtp_auth_mechanism": null,
"smtp_debug": false,
"smtp_explicit_tls": false,
"smtp_from": "",
"smtp_from_name": "Vaultwarden",
"smtp_host": null,
"smtp_password": null,
"smtp_port": 587,
"smtp_ssl": true,
"smtp_timeout": 15,
"smtp_username": null,
"templates_folder": "data/templates",
"trash_auto_delete_days": null,
"trash_purge_schedule": "0 5 0 * * *",
"use_syslog": false,
"user_attachment_limit": null,
"web_vault_enabled": true,
"web_vault_folder": "web-vault/",
"websocket_address": "0.0.0.0",
"websocket_enabled": true,
"websocket_port": 3012,
"yubico_client_id": "72697",
"yubico_secret_key": "***",
"yubico_server": null
}
```
</details>
#### docker-compose.yml
```yaml
version: "3.6"
services:
bitwarden:
environment:
- "WEBSOCKET_ENABLED=true"
- YUBICO_CLIENT_ID
- YUBICO_SECRET_KEY
- ADMIN_TOKEN
image: vaultwarden/server:latest
expose:
- "80"
- "3012"
restart: on-failure
volumes:
- ./data:/data
swag: # let's encrypt
image: linuxserver/swag
cap_add:
- NET_ADMIN
restart: on-failure
environment:
PUID: "1000"
PGID: "1000"
TZ: America/Los_Angeles
URL: # [REDACTED]
VALIDATION: http
SUBDOMAINS: # [REDACTED]
ONLY_SUBDOMAINS: "true"
ports:
- "443:443"
- "80:80"
- "3012:3012"
volumes:
- ./swag-config:/config
```
Note: `YUBICO_CLIENT_ID`, `YUBICO_SECRET_KEY`, and `ADMIN_TOKEN` are provided in my `.env` file.
### Steps to reproduce
1. Start the server with `docker-compose up`.
2. Log in using the web app, and add your Yubikey OTP as your two-step authentication.
3. Stop and remove the docker containers using `docker-compose down`.
4. Re-create and start the docker containers using `docker-compose up`.
5. Try to login and use your Yubikey OTP as two-step authentication.
### Expected behaviour
I should be able to log in with the Yubikey OTP I set up before.
### Actual behaviour
The web app says "Given Yubikey is not registered" when I try to use the Yubikey OTP as two-step authentication.
### Troubleshooting data
When I try to log into the newly created container, I get the following error:
```txt
bitwarden_1 | [2022-04-03 09:07:25.072][request][INFO] POST /identity/connect/token
bitwarden_1 | [2022-04-03 09:07:25.092][vaultwarden::api::core::two_factor::yubikey][ERROR] Given Yubikey is not registered
bitwarden_1 | [2022-04-03 09:07:25.092][response][INFO] POST /identity/connect/token (login) => 400 Bad Request
```
I see you didn't configured the DOMAIN variable (Or you removed it), but that is really needed for MFA Tokens.
Also could you please provide the output of the Support String which you can generate via the admin panel /admin/diagnostics?
And.. What if you do not shutdown the the container, can you then logout and back in?
And, what happens if you try it again right after the first failed attempt?
@BlackDex commented on GitHub (Apr 3, 2022):
I see you didn't configured the DOMAIN variable (Or you removed it), but that is really needed for MFA Tokens.
Also could you please provide the output of the `Support String` which you can generate via the admin panel `/admin/diagnostics`?
And.. What if you do not shutdown the the container, can you then logout and back in?
And, what happens if you try it again right after the first failed attempt?
I do have the Domain URL variable correctly configured under General Settings. Under the diagnostics page, it says Domain configuration [Match] [HTTPS]. (I believe the domain variable is automatically censored for the support string.) Is there more I need to configure?
Here's the support string copied from /admin/diagnostics:
Your environment (Generated via diagnostics page)
Vaultwarden version: v1.24.0
Web-vault version: v2.25.1
Running within Docker: true (Base: Debian)
Environment settings overridden: true
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: SQLite
Database version: 3.35.4
Clients used:
Reverse proxy and version:
Other relevant information:
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden: ADMIN_TOKEN, YUBICO_CLIENT_ID, YUBICO_SECRET_KEY
Could you try this also with the current testing tagged image please. Sand see if that also behaves the same. I do suggest to create a backup of the database btw before you do this.
@BlackDex commented on GitHub (Apr 5, 2022):
Could you try this also with the current `testing` tagged image please. Sand see if that also behaves the same. I do suggest to create a backup of the database btw before you do this.
Going to close this issue as there is no response and until now nobody else reported an issue like this.
If this issue still occurs, please re-open with the an answer the the above questions and more details.
@BlackDex commented on GitHub (Apr 23, 2022):
Going to close this issue as there is no response and until now nobody else reported an issue like this.
If this issue still occurs, please re-open with the an answer the the above questions and more details.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @mtnakayama on GitHub (Apr 3, 2022).
Yubikey OTP not persistent after re-creating Docker container
Yubikey OTP is not persistent when destroying and re-creating a vaultwarden docker container, even when the
/datavolume is mounted.Deployment environment
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden: ADMIN_TOKEN, YUBICO_CLIENT_ID, YUBICO_SECRET_KEY
docker-compose.yml
Note:
YUBICO_CLIENT_ID,YUBICO_SECRET_KEY, andADMIN_TOKENare provided in my.envfile.Steps to reproduce
docker-compose up.docker-compose down.docker-compose up.Expected behaviour
I should be able to log in with the Yubikey OTP I set up before.
Actual behaviour
The web app says "Given Yubikey is not registered" when I try to use the Yubikey OTP as two-step authentication.
Troubleshooting data
When I try to log into the newly created container, I get the following error:
@BlackDex commented on GitHub (Apr 3, 2022):
I see you didn't configured the DOMAIN variable (Or you removed it), but that is really needed for MFA Tokens.
Also could you please provide the output of the
Support Stringwhich you can generate via the admin panel/admin/diagnostics?And.. What if you do not shutdown the the container, can you then logout and back in?
And, what happens if you try it again right after the first failed attempt?
@mtnakayama commented on GitHub (Apr 3, 2022):
I do have the
Domain URLvariable correctly configured underGeneral Settings. Under the diagnostics page, it saysDomain configuration [Match] [HTTPS]. (I believe the domain variable is automatically censored for the support string.) Is there more I need to configure?Here's the support string copied from
/admin/diagnostics:Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden: ADMIN_TOKEN, YUBICO_CLIENT_ID, YUBICO_SECRET_KEY
Yes, I can log in using Yubikey OTP as many times as I want after I set it up. I only get these issues after I destroy and re-create the container.
Trying again after the first failed attempt results in the same error.
@BlackDex commented on GitHub (Apr 5, 2022):
Could you try this also with the current
testingtagged image please. Sand see if that also behaves the same. I do suggest to create a backup of the database btw before you do this.@BlackDex commented on GitHub (Apr 12, 2022):
@mtnakayama any update on this?
@BlackDex commented on GitHub (Apr 23, 2022):
Going to close this issue as there is no response and until now nobody else reported an issue like this.
If this issue still occurs, please re-open with the an answer the the above questions and more details.