[support] Vaultwarden (formerly Bitwarden_rs)


Recommended Posts

  • 2 weeks later...
On 2/12/2020 at 4:50 PM, Roxedus said:

So bitwardenrs:server is drop-in replaceable with mprasil's container. The same environment variables and so on.
ADMIN_TOKEN is unrelated to the admin password, it's a string you create yourself. Either generate a random one (preferred), or just button smash on your keyboard. You don't really need to remember it, as you can change it if you really need to go into the admin panel.

Can we pin this to near the front page? I had to do some digging to see what ADMIN_TOKEN was supposed to be :)

Link to comment
  • 3 weeks later...
On 1/1/2023 at 9:23 AM, Maginos said:

 @hata:
I have the same issue as you guys, I have to use version 1.24.0 and it's not possible to upgrade to a higher version. I get the same output in the log as gizmer (on page 20).
Have you been able to upgrade the vaultwarden docker meanwhile to 1.25.0 or higher and if yes, how did you do that?

I ended up fixing things today. I couldn’t login to my vault no matter what, guess the newer bitwarden clients are incompatible.

So I added the vaultwarden container from the app repo (my old was was still named bitwarden for some reason) to my dockers.

And just exported my old users vault as json and imported it in the new server under my user account.

Everything seems fine so far. I didn’t have to do anything other than basic setup on the new container, just put in an admin token, put my hostname, setup email under the admin page, and sent myself an invite. Maybe there was more little things, can’t remember.

And I’d like to just note that switching the tag to :latest didn’t work on my old container, not sure what the issue there was. Container still ran, just couldn’t login.

Link to comment
  • 2 weeks later...
On 2/3/2023 at 12:52 PM, hata said:

I ended up fixing things today. I couldn’t login to my vault no matter what, guess the newer bitwarden clients are incompatible.

So I added the vaultwarden container from the app repo (my old was was still named bitwarden for some reason) to my dockers.

And just exported my old users vault as json and imported it in the new server under my user account.

Everything seems fine so far. I didn’t have to do anything other than basic setup on the new container, just put in an admin token, put my hostname, setup email under the admin page, and sent myself an invite. Maybe there was more little things, can’t remember.

And I’d like to just note that switching the tag to :latest didn’t work on my old container, not sure what the issue there was. Container still ran, just couldn’t login.

I had the same issue and the issue is SWAG NGIX has a bug in the latest update. I just had to go to the SWAG docker console and rm /etc/nginx/conf.d/stream.conf after that all worked.

Link to comment
  • 2 weeks later...

Alright, I had a dumb issue, couldn't find the answer, but figured it out.  Here's some keywords incase someone google it like me in the future:

I had this error in my logs:

[rocket::server][WARN] Received SIGTERM. Requesting shutdown.

It turned out that my BitWarden / ValultWarden server was competing for the same static IP address that was already assigned to my Nvidia Shield. 

I fiddled with my Nginx proxy, and visiting it direct, and my dynamic dns, but in the end it was just an IP assignment conflict.

 

As soon as my shield was off the network, VaultWarden was happy again.

Edited by pale2hall
additional clarification
Link to comment

I'm running into a strange 502 Bad Gateway issue with the latest proxy configuration file in swag (so this may be a swag problem rather than a bitwarden docker one).

 

Currently using the 2022-09-08 file version and made my setting changes to the newer 2023-02-13 version of bitwarden.subdomain.conf and the only new changes are the Authentik settings (which are commented out) and the following:

 

 location ~ (/bitwarden)?/api {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app bitwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

 

Everything is exactly the same except for this section in both files, but running swag using this one returns a bad gateway error and my vault is blank when accessing it from the browser.  Switching back to the previous conf file, everything is back to normal.  Any ideas what's going or if I am missing something else to adjust elsewhere?

Link to comment

does anyone else have problem sending files of 160MB using the send tool ?

 i does say that support 500 MB but i get aeeror on 160MB files 

 

An Error has occured 
Failed to fetch

 

[2023-03-03 19:35:17.181][request][INFO] POST /api/sends/file/v2
03/03/2023 19:35:17
[2023-03-03 19:35:17.184][response][INFO] (post_send_file_v2) POST /api/sends/file/v2 => 200 OK
03/03/2023 19:39:30
[2023-03-03 19:39:30.769][request][INFO] DELETE /api/sends/93df4fdc-3df8-4311-a31a-d07347d4ded7
03/03/2023 19:39:30
[2023-03-03 19:39:30.770][request][INFO] DELETE /api/sends/563c642d-0fb7-4dd8-8be7-9f152a645ba7
03/03/2023 19:39:30
[2023-03-03 19:39:30.781][response][INFO] (delete_send) DELETE /api/sends/<id> => 200 OK
03/03/2023 19:39:30
[2023-03-03 19:39:30.783][response][INFO] (delete_send) DELETE /api/sends/<id> => 200 OK

 

this is using the app

Version 2023.2.0 Shell 21.3.1 Renderer 106.0.5249.181 Node 16.16.0 Architecture x64

 

also using the plugin same error, either on opera or brave

Link to comment
On 2/27/2023 at 4:53 PM, avinyc said:

I'm running into a strange 502 Bad Gateway issue with the latest proxy configuration file in swag (so this may be a swag problem rather than a bitwarden docker one).

 

Currently using the 2022-09-08 file version and made my setting changes to the newer 2023-02-13 version of bitwarden.subdomain.conf and the only new changes are the Authentik settings (which are commented out) and the following:

 

 location ~ (/bitwarden)?/api {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app bitwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

 

Everything is exactly the same except for this section in both files, but running swag using this one returns a bad gateway error and my vault is blank when accessing it from the browser.  Switching back to the previous conf file, everything is back to normal.  Any ideas what's going or if I am missing something else to adjust elsewhere?

Resolved - set $upstream_app needs to match the container name (in my case bitwardenrs) and I have not been updating all the sections with each updated .conf file.  The addition of the location api commands triggered the bad gateway even though others were not necessary.  All now match and everything works from web, extension and app.

 

While this is technically a vaultwarden issue, I think it would have been better placed in the swag support thread.

Link to comment
  • 3 weeks later...

Hello.

I just installed Vaultwarden onto my unraid server version 6.11.5. I set it up using a swag reverse proxey. I made it through the authentication set up the stmp information and invited myself to be a user.

I was able to set up the new account and create a master passowd and sign into vaultwarden.

unfortunatlly anything I try to do from that page results in an error

 

<html>

<head><title>502 Bad Gateway</title></head>

<body>

<center><h1>502 Bad Gateway</h1></center>

<hr><center>nginx</center>

</body>

</html>

<!-- a padding to disable MSIE and Chrome friendly error page -->

<!-- a padding to disable MSIE and Chrome friendly error page -->

<!-- a padding to disable MSIE and Chrome friendly error page -->

<!-- a padding to disable MSIE and Chrome friendly error page -->

<!-- a padding to disable MSIE and Chrome friendly error page -->

<!-- a padding to disable MSIE and Chrome friendly error page -->

 

I'm completely lost on what to try to get this working, any assistance would be greatly appreciated.

 

Chas

Link to comment

Looking at the docker container, it says the latest version is not available.  The repository is vaultwarden/server.  Also looking at the logs I tend to see this recurring entry:

 

[2023-03-27 07:53:12.811][_][WARN] Responding with registered (not_found) 404 catcher.
[2023-03-27 07:53:13.081][_][WARN] Response was `None`.

Untitled.jpg

  • Upvote 2
Link to comment

  log showing

[NOTICE] You are using a plain text `ADMIN_TOKEN` which is insecure.
Please generate a secure Argon2 PHC string by using `vaultwarden hash` or `argon2`.
See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token

 

THE FIX


⚠️This feature is released in 1.28.0+. Previous versions do not support Argon2 hashing.

 

# Using the OWASP minimum recommended settings

 

Open command prompt and run

docker exec -it vaultwarden /vaultwarden hash --preset owasp

 

This will generate a PHC string

Generate an Argon2id PHC string using the 'owasp' preset:

Password:MYSECRETEPASSWORD
Confirm Password:MYSECRETEPASSWORD

ADMIN_TOKEN='copy everything inside ' ' only, this is the new generated PHC string'

 

MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store.

MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store.

MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store.


NOTE/SAVE/STORE/COPY - the output of the new generated PHC string ADMIN_TOKEN. everything inside ' ' only.


Edit your vaultwarden docker container, and paste in the new PHC generated ADMIN_TOKEN string.
Save/Restart container.

 

Navigate to your vaultwarden admin panel, enter your existing (old) plain text ADMIN_TOKEN.

Go to, Settings > General settings > Admin page token: paste in your generated ADMIN_TOKEN string (everything inside ' ' only).
Save, admin panel.
restart container.

 

check logs, notice the [NOTICE] warning no longer present.
done.
 

See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token for other options.

Edited by Tolete
  • Like 3
  • Thanks 3
Link to comment
10 hours ago, Tolete said:

  

[NOTICE] You are using a plain text `ADMIN_TOKEN` which is insecure.
Please generate a secure Argon2 PHC string by using `vaultwarden hash` or `argon2`.
See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token

 

THE FIX


⚠️This feature is released in 1.28.0+. Previous versions do not support Argon2 hashing.

 

# Using the OWASP minimum recommended settings

 

Open command prompt and run

docker exec -it vaultwarden /vaultwarden hash --preset owasp

 

This will generate a PHC string

Generate an Argon2id PHC string using the 'owasp' preset:

Password:MYSECRETEPASSWORD
Confirm Password:MYSECRETEPASSWORD

ADMIN_TOKEN='copy everything inside ' ' only, this is the new generated PHC string'

 

MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store.

MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store.

MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store.


NOTE/SAVE/STORE/COPY - the output of the new generated PHC string ADMIN_TOKEN. everything inside ' ' only.


Edit your vaultwarden docker container, and paste in the new PHC generated ADMIN_TOKEN string.
Save/Restart container.

 

Navigate to your vaultwarden admin panel, enter your existing (old) plain text ADMIN_TOKEN.

Go to, Settings > General settings > Admin page token: paste in your generated ADMIN_TOKEN string (everything inside ' ' only).
Save, admin panel.
restart container.

 

check logs, notice the [NOTICE] warning no longer present.
done.
 

See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token for other options.

Thank you for sharing!

Not sure if just myself or...once I set ENV Variable in the container settings and rebooted container I did NOT have to go into Vaultwarden admin panel and set Admin_Toke again. On my first of two instances I did that and I ended up having to delete the ENV variable in container settings. 

On my second instance, i just set the ENV variable in container settings, rebooted container and all picked up fine and didn't fuss about "ADMIN_TOKEN" being set in config file AND with a ENV.

Never the less works great, thank you!

EDIT: I lied; on second instance I had to do same as far as set in admin panel and delete the ENV in container settings. Kept getting: 

[2023-03-28 06:26:59.295][vaultwarden::api::admin::_][WARN] Request guard `AdminToken` failed: "Unauthorized".

In the logs until I did

Edited by blaine07
Link to comment
22 hours ago, Gragorg said:

Go to App Store and install Squids “Docker Patch”. A lot of dockers can’t update without it. Supposed to be patched in next Unraid release. 

I'm on version 6.9.2, so it isn't a bug with a new version.  Additionally, Squid's docker patch app isn't available in the app store (presumably because I am on an older version of unraid).

  • Like 1
Link to comment
On 3/28/2023 at 3:50 AM, Tolete said:

Using the OWASP minimum recommended settings

 

Using the Bitwarden defaults is not better ?

in other side after using this (Bitwarden defaults hash) and changed Password iteration from old default 100000 to new 350000 

entering to vault from phone take a couple of seconds ....

Link to comment
6 hours ago, Masterwishx said:

 

Using the Bitwarden defaults is not better ?

in other side after using this (Bitwarden defaults hash) and changed Password iteration from old default 100000 to new 350000 

entering to vault from phone take a couple of seconds ....

 

password iterations-

Whether using the Bitwarden defaults is better or not depends on your individual security needs and preferences. Bitwarden's default settings are designed to provide a good balance between security and usability for most users. However, some users may have higher security requirements or preferences, and may choose to adjust the settings accordingly.
 

Increasing the password iteration from 100,000 to 350,000 will indeed make it harder for attackers to crack your password, as it will take them longer to test each potential password. However, this also means that it will take longer for you to log in to your vault, especially on devices with slower processors.
 

Ultimately, it is up to you to decide which settings work best for you. You should consider your individual security needs and preferences, as well as the performance of your devices when making these decisions. If you find that the increased password iteration is causing significant delays in accessing your vault from your phone, you may want to consider reducing it to a level that provides a good balance between security and usability.

 

as for the 'OWASP minimum recommended settings'-

this changes your 'ADMIN_TOKEN' from a plain text token (insecure) to a PHC string (secure).

 

 

  • Like 1
Link to comment
4 hours ago, Tolete said:

Increasing the password iteration from 100,000 to 350,000 will indeed make it harder for attackers to crack your password

 

Vaultwarden default changed to 350000 and bitwarden to 600000

But I thought password iteration it's in server side not client. 

 

After changed Token to hash having 2 warning like posted above but all working.... 

Thanks for explaining... 

Link to comment
On 3/30/2023 at 8:32 PM, Johnny Utah said:

Yeah I am on 6.10.0 and having the same issue.

 

Same here, running 6.9.2.  Refuse to upgrade, I have 2 VMs (Windows 11 and Server 2019) licensed and don't want to spend again on these licenses or go through the hassle of contacting Microsoft and/or getting video passthru working.

 

EDIT:  Found this workaround...

 

Edited by EArroyo
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.