I have VaultWarden (VW) v2.19.0 running in a container, and all is well.
Except, I cannot get CLI to recognize bw
The docs says to use i.e bw import command to import a pwd file. But when I’m iside the container, all I get is bash: bw: command not found
So, I need help to figure out where to find this executable inside the container as it is obviously not on the path.
Hi, and thanks for stepping in
I was just doing what the docs told me to do: Bitwarden CLI | Bitwarden Help & Support
So, please tell med what CLI command I should be using, since bw is obviously wrong.
I’m not sure I understand.
I began by searching for BW on Docker HUB, and what I found was tagged with “Depreciated - use VW instead”. So I did. But whenever I search the web for docs, all I can find is BW docs. So, I assumed that it was identical - except for the name which had changed.
Anyway, there must be a way to import password files into VW also, right?
That’s what I want to do.
Sorry for being such a newbie here - but I still don’t understand.
I have no desire what so ever to use any BW stuff if I can avoid it.
So, there must be a nativ way to import a password file into VW, or… ?
I did read that - almost all of it.
But I do not fully understand where the line is drawn between my self-hosted instance and the online version. I do not want to send my password file to an online service (if I can avoid it). That’s why I decided to go for a self-hosted version in the first place.
Why release a stand-alone self-hosted version of a password manager when users still have to rely on an online service to use it?
I did visit vault.bitwarden.com and was asked to log in (which I didn’t) Does this online version know my newly established local user account and my secret personal credentials ?
So, I guess I still don’t understand…
You have to see Vaultwarden as a Self-Hosted solution, so all articles at bitwarden.com regarding to Self-Hosted also apply to Vaultwarden, with some minor differences to configuration and some missing features.
I’m not using any clients (and I have no plans to do so).
I use a nativ Chrome Browser on my desktop PC to connect to vw.mydomain.com
That’s all.
Could you please explain the issue I raised:
I do not want to send my password file to an online service (if I can avoid it). That’s why I decided to go for a self-hosted version in the first place.
Why release a stand-alone self-hosted version of a password manager when users still have to rely on an online service to use it?
I did visit vault.bitwarden.com and was asked to log in (which I didn’t) Does this online version know my newly established local user account and my secret personal credentials ?
I think you do not understand how this works.
All the clients can connect to any server, including self-hosted, including the Vaultwarden Rust based API Compatible Server.
If you do not want to use any of the clients provided by Bitwarden.com then you just need to connect to https://vw.mydomain.com/ and use that, there is no more too it (Though technically that web interface is a one-on-one copy with some modifications coming from Bitwarden.com).
I don’t know why you want or need to go to vault.bitwarden.com, it has no connection to Vaultwarden in any way.
Aha! That’s what I was looking for (and couldn’t find): Tools > Import Data
I’m so sorry for being a newbie - and I’m so grateful for your patient and help.
I think I completely failed to understand that where the docs read vault.bitwarden.com I have to replace that with vw.mydomain.com
There’s light at the end of the tunnel
Hehe, no prob.
We tried to be less confusing by changing the name to vaultwarden and making sure there is a difference, but still we do use there sources and API to have it all working.
Because without bitwarden, there wouldn’t be a vaultwarden either.
Today, I finally made it work.
I had to create a separate certificate just for VW without any additional names attached to it, and I had to split the certificate and key file into two separate files. The BW Android client failed to accept a combined PEM file.
I must say I’m a bit disappointed if my findings reveal the fact that whoever made this client, failed to comply with basic standard certificate usage. Should I trust my most valuable list of passwords to them?
On the other hand, if these discrepancies from the standard (as I see it), are deliberate because “someone” thinks it somehow enhances security (?), then it should have been documented somewhere, don’t you agree?