Bitwarden - Self-hosted password manager

necrevistonnezr

Tried updating the bitwardenrs-app today to its current domain; usually it would just install (and upgrade) the app. Today I got the following error:

➜ cloudron install
ERROR (node:9463) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. [ internal/process/warning.js:27:3 ]
Location: bit
ERROR Failed to install app. Domain 'bitwarden.domain.com' is in use [ /Users/user/.nvm/versions/node/v12.7.0/lib/node_modules/cloudron/src/helper.js:68:29 ]

necrevistonnezr

Tried with the LTS node version today - still the same error "Domain is in use". Anyone have an idea why?

girish

@necrevistonnezr You have to delete the DNS entry manually in the DNS provider. What's hapenned is that the dns already has an entry for the subdomain. Cloudron will never overwrite existing DNS records.

This is getting fixed with https://git.cloudron.io/cloudron/box/issues/644. Cloudron will then overwrite DNS entries with that flag set.

If the above is not the issue, maybe there is another app on that subdomain? (Also, check any redirects you have to set for other apps).

necrevistonnezr

@girish said in Bitwarden - Self-hosted password manager:

@necrevistonnezr You have to delete the DNS entry manually in the DNS provider. What's hapenned is that the dns already has an entry for the subdomain. Cloudron will never overwrite existing DNS records.

Where am I supposed to delete the DNS entry? Is the "DNS provider" something in the cloudron control panel?

I have no other apps / redirects regarding that subdomain.

d19dotca

@necrevistonnezr - He means delete the DNS entry from your DNS service provider itself for the domain. So if you already have bitwarden.domain.com in your DNS listing for your domain, then remove the bitwarden entry and then re-create with Cloudron.

necrevistonnezr

@d19dotca said in Bitwarden - Self-hosted password manager:

@necrevistonnezr - He means delete the DNS entry from your DNS service provider itself for the domain. So if you already have bitwarden.domain.com in your DNS listing for your domain, then remove the bitwarden entry and then re-create with Cloudron.

That was not the issue since I did not have a subdomain entry in my DNS settings (I have a wildcard DNS entry). The issue was that cloudron-cli was not able to connect to my cloudron properly (TLS, https issues) for reasons I don't know (I told support about it).

After using cloudron login --allow-selfsigned I was able to build and update the bitwarden...

d19dotca

@necrevistonnezr Ah interesting, good to know you figured that out then. Normally when that error is seen (I came across it quite a lot when setting up new environments on Cloudron as I learned the platform), it was always because I had already defined a "www" subdomain in my DNS provider, for example, so it then needed me to remove it before it could create it automatically by itself.

iamthefij

Ok. So I think I've just figured out the email issue, but don't have a fix yet.

When using the non-smtps connection, the logs show that lettre, the Rust email library that Bitwarden_rs uses, recognizes that the server supports several authentication methods, including Authentication(Plain), which is what swacks uses when successfully sending on the same port. However, lettre refuses to use it because we aren't using an encrypted connection and it doesn't want to send credentials in the clear. (Checked here, defined as empty here).

Unfortunately, using smtps is not a solution either because it appears that lettre is trying to validate the certificate, but that certificate is invalid.

A patch to Bitwarden_rs may be required to tell lettre to allow sending credentials over an insecure connection using this method or by telling it to accept insecure certs.

I'm working on a patch for Bitwarden_rs to allow insecure SSL connections so that it will accept a self signed cert.

iamthefij

Also, it looks like MySQL support is available now. Once I get all the email support sorted out, I'll try to roll that in as well.

iamthefij

@iamthefij Ok. My bitwarden_rs patch works. I'm going to submit that upstream.

girish

@iamthefij Talking to yourself again ?

iamthefij

On another note... There is no Docker image built for MySQL support yet, so I'm writing a new Dockerfile that uses a multi stage built to compile Bitwarden_rs with MySQL support.

fbartels

@iamthefij there is one already at https://github.com/dani-garcia/bitwarden_rs/tree/master/docker/amd64/mysql

iamthefij

@fbartels yes. But not an image on Docker Hub that I can pull from. Instead I'm building a multistage build that looks a lot like that Dockerfile but with the an LDAP layer and the Cloudron layer.

fbartels

@iamthefij it's here https://hub.docker.com/r/bitwardenrs/server-mysql

iamthefij

@fbartels well, I guess I didn't look hard enough! (Edit: Looks like the 1.10.0 release was only 2 hours ago. No wonder I missed it. ) It would be good to roll those all into one image with multiple tags, but I can chat with them about that on Matrix.

Anyway, adding the multi-stage build wasn't terribly hard and cuts out an extra dependency on that build pipeline, which is probably a good thing for a security sensitive project.

Latest on my master is now fully operational. Working email, working ldap sync, working MySQL.

BIG WARNING! There is no migration path from SQLite to MySQL. You should export your vault to CSV or something and then re-import it after migration.

https://git.cloudron.io/iamthefij/bitwardenrs-app

necrevistonnezr

@iamthefij Maybe the migration scripts by the author work that are mentioned here?

* Start bitwarden_rs with and empty mysql database, so diesel can run migrations and set up the schema properly. Do not do anything else.
* Stop bitwarden_rs.
* Dump your existing sqlite database: sqlite3 db.sqlite3 .dump > sqlitedump.sql
* Drop schema creation and diesel metadata from your dump, leaving only your actual data: grep "INSERT INTO" sqlitedump.sql | grep -v "__diesel_schema_migrations" > mysqldump.sql

* Load your MySQL dump: mysql -u bitwarden -p bitwarden < mysqldump.sql

* Start bitwarden_rs
ˋˋˋ

iamthefij

@necrevistonnezr I saw that. Yea, it's possible to do, but it's not something that I think is worth automating given that it could be a bit finicky.

If someone wants to do this, they are welcome to try using the console.

I'm planning to just export and re-import myself.

necrevistonnezr

@iamthefij but import / export does not work for attachments, right? Or are these somehow migrateable?

iamthefij

@necrevistonnezr hmm. I've got no clue. I don't have any attachments and only use Bitwarden to manage passwords.

lukaszj

@iamthefij I've used your build with fixed emails and ldap and it installed well however I'm not sure how to get in.

Bitwarden asks for email so I supply email corresponding to my Cloudron login and Cloudron's password but it says username or password is invalid. Can you suggest something?

iamthefij

@lukaszj you should receive an invite email within a few min of the sync task running. I think it runs every 5 min. You'll need to click the link in that email to create your account.

jimcavoli

With all the activity on this thread, is it likely that Bitwarden will see release in the App Store any time soon? Even as an "unstable" package for easier trial by others?

girish

@jimcavoli We will take this up next week since we are working on getting 4.2 out this week. Will follow up with @iamthefij on what the status is.

iamthefij

@girish it should be good to go. My branch is working with MySQL and LDAP.

I've got two working Dockerfiles. One that compiles the entire project and another that just pulls the binary from the published images on Docker Hub. End result is the same.

lukaszj

Hello @girish is there any progress with releasing Bitwarden to App Store? Thanks!

girish

Unfortunately, not this week. The 4.2 release hit some hiccups. Good news is that we are rolling out 4.2 as we speak. So, we should get to this next week.

lukaszj

@girish Great, can't wait. Fingers crossed!

iamthefij

@girish great to hear! Let me know if there is anything I can do to help.

necrevistonnezr

Again, there's trouble with cloudron cli. I tried to login but it gives me the following errors:

cloudron login --allow-selfsigned
Cloudron Admin Domain: my.domain.com
ERROR (node:51749) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. [ internal/process/warning.js:27:3 ]
ERROR Cloudron my.domain.com not found.
Try providing the admin location, probably my.my.domain.com [ /Users/user/.nvm/versions/node/v12.7.0/lib/node_modules/cloudron/src/helper.js:71:29 ]

What am I doing wrong?

girish

@necrevistonnezr You almost never have to use --allow-selfsigned Does my.domain.com have the correct cert?

necrevistonnezr

@girish Yes, the situation is the same with or without "--allow-selfsigned"
BTW I'm on macOS 10.15

girish

@necrevistonnezr Can you try using the CLI on the demo cloudron? Like:

cloudron login my.demo.cloudron.io

username and password is cloudron. you can then build and install there. does that entire flow work?

necrevistonnezr

@girish that gives me the same error but pinging works

bitwardenrs-app on master [!?] via ⬢ v12.7.0
➜ cloudron login my.cloudron.io
ERROR (node:55034) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. [ internal/process/warning.js:27:3 ]
ERROR Cloudron my.cloudron.io not found.
Try providing the admin location, probably my.my.cloudron.io [ /Users/kdj/.nvm/versions/node/v12.7.0/lib/node_modules/cloudron/src/helper.js:71:29 ]
bitwardenrs-app on master [!?] via ⬢ v12.7.0 took 18s
➜ ping my.cloudron.io
PING my.cloudron.io (45.55.2.141): 56 data bytes
64 bytes from 45.55.2.141: icmp_seq=0 ttl=50 time=188.063 ms
64 bytes from 45.55.2.141: icmp_seq=1 ttl=50 time=181.041 ms
64 bytes from 45.55.2.141: icmp_seq=2 ttl=50 time=237.531 ms

lukaszj

Hi @girish is there any update re pushing official Bitwarden to Marketplace? Thanks.

girish

@lukaszj No ETA but it's on our immediate list. Currently, we are pushing out the release that makes it possible to build custom apps without our build service.

lukaszj

@girish Thanks.

murgero

@girish But building apps without the build service is already possible - do you mean that the manifest will allow us to specify a repo and docker image to install? Cause that would be nice!

girish

Just started looking into getting this package published. I also found a related https://github.com/dani-garcia/bitwarden_rs/pull/677 .

iamthefij

@girish I'd be neat if that gets merged, but the maintainers rejected a previous patch for direct LDAP support and that's why it was moved to a different binary. See comments here: https://github.com/dani-garcia/bitwarden_rs/pull/396#issuecomment-464059020

iamthefij

Hey @girish any updates on this? I've been holding off on migrating from my external instance to my Cloudron one because I'm not sure about the process of migrating from the dev one to an official one. Any guidance on when to expect this or if it's possible to preserve the Docker volume would be helpful.

will

@iamthefij said in Bitwarden - Self-hosted password manager:

Hey @girish any updates on this? I've been holding off on migrating from my external instance to my Cloudron one because I'm not sure about the process of migrating from the dev one to an official one. Any guidance on when to expect this or if it's possible to preserve the Docker volume would be helpful.

I'm in the same boat. I am maintaining a VPS solely for Bitwarden access. Would save $10 a month and time if I could roll this out! Thanks for all the hard work!

I tried deploying the Cloudron Bitwarden like below:

Commands run on Cloudron server.

git clone https://git.cloudron.io/fbartels/bitwardenrs-app #Successfully clones to home directory
npm install -g cloudron-cli **#Command fails, no cloudron-cli **
cloudron build # this will ask your cloudron.io login #Never got to this stage
cloudron install # this will ask you for your cloudron's login #Never got to this stage

murgero

@will Those commands do NOT get ran on the cloudron server.

The cloudron CLI is ONLY for use outside of the server (it's the management tool for cli users)

At home, install virtualbox on your computer and create an ubuntu VM. (If you already have a computer with linux, ignore this step, these steps can be installed in windows if you install nodejs and git first)

Then run:

git clone https://git.cloudron.io/fbartels/bitwardenrs-app
cd bitwardenrs-app
## Install NodeJS from https://nodejs.org/en/download/package-manager/
npm install -g cloudron
cloudron build
cloudron install

will

@murgero Thanks! I'm running windows subsystem for linux so I'll give it a shot. Thanks again!

murgero

@will If you plan on building apps using a local docker install, that can only be done on linux (not the subsystem), otherwise using a build service (either the app one or cloudron's cloud build service) is good on any system with nodejs support

will

@murgero I'm not a developer, but I have stumbled my way through rough spots before. Just so I understand the workflow.
So lets say I want to deploy the Bitwarden app on my Cloudron instance in production (I don't but let's roll with it for a sec)
I would configure my dev environment (install Nodejs, cloudron-cli, and install Cloudron build service app on the Web Store)
I would clone the app I wanted to play with to my local dev machine, cd into that directory and use the cloudron build command to bush this app to the Cloudron Build Service App?
Lastly use the cloudron install command to install the app on to my production instance.
How close am I to the right answer?

Thanks again for taking the time out to help me out. I'm trying to understand this stuff, but it's way out of my swimlane.

murgero

@will I don't use the build service app because it can delete other apps mistakenly. I use the following process for building my apps (step by step, literally) using a local linux machine with Docker, npm, git, and cloudron-cli.

Just make sure you have a free dockerhub account

git clone https://github.com/mitchellurgero/cloudron-vscode
cd cloudron-vscode

## Change as you need!
docker build -t dockername/projectname:tagname .
docker push dockername/projectname:tagname

## End docker changes
cloudron login
cloudron install --image dockerhuburl/dockername/projectname:tagname

Example commands when replacing the variables with real items:

git clone https://github.com/murgero/MyApp1-cloudron
cd MyApp1-cloudron

## Change as you need!
docker build -t murgero/MyApp1:latest .
docker push murgero/MyApp1:latest

## End docker changes
cloudron login
cloudron install --image dockerhuburl/murgero/MyApp1:latest

iamthefij

FYI @murgero @will I don’t think that git repo has any of the fixes or changes I’ve added. Try the one I linked much earlier. (I’m on mobile so I can’t link it now).

fbartels

@murgero building is much easier now. when you call cloudron build it will ask for the registry to upload to. so you just have to enter your-username/your-chosen-name-for-the image, e.g. fbartels/cloudron-bitwardenrs. cloudron install will then automatically use this image.

@will I am still not a huge believer in the ldap sync and the mysql backend of bitwarden. I have updated my repo to the last version and also picked some smtp things from @iamthefij. Sending invites still does not seem to work, will need to look further into this.

Edit: Managed to fix the issue with sending invites. the value of SMTP_AUTH_MECHANISM needs to be quoted, but when exporting it, these quotes are normally removed. Working and up to date version is in the git repo.

iamthefij

@fbartels what issues are you having with the LDAP sync?

fbartels

@iamthefij its not a technical problem, the approach isn't bad either. I think both (LDAP and MySQL) simply add unneeded complexity.

murgero

@fbartels said in Bitwarden - Self-hosted password manager:

building is much easier now. when you call cloudron build it will ask for the registry to upload to. so you just have to enter your-username/your-chosen-name-for-the image, e.g. fbartels/cloudron-bitwardenrs. cloudron install will then automatically use this image.

This requires the build service app to be installed on your cloudron which currently has a warning attached to it that it may delete USED docker images from other apps. Until the build service app is more stable, I'll stick to my sure-fire, tried and true way

fbartels

@murgero said in Bitwarden - Self-hosted password manager:

This requires the build service app to be installed on your cloudron

That is not true. Its build locally and then pushed into the github account.

iamthefij

@fbartels I see. Yea, totally agree that it’s not really necessary for most folks usage. The instance I run outside of Cloudron today uses neither of them. I’m using it as a simple personal password manager.

I believe Cloudron tends to prefer configurations that are ready for a small enterprise. My personal Gogs server was fine with SQLite and local auth as well, but Cloudron is configured with MySQL and LDAP.

‍️

yusf

I think it’s important to scale for at least 50 intended users for Cloudron apps. I think that this number is even specified in the docs somewhere.

necrevistonnezr

@fbartels said in Bitwarden - Self-hosted password manager:

@murgero said in Bitwarden - Self-hosted password manager:

This requires the build service app to be installed on your cloudron

That is not true. Its build locally and then pushed into the github account.

When I try to update my bitwarden app at the existing domain 'bit.mydomain.de' this way, I still get a

Failed to install app: 409 message: Domain 'bit.mydomain.de' is in use

I have a wildcard DNS entry), so a DNS entry for the subdomain should not cause trouble. I also tried cloudron login --allow-selfsigned but it doesn't change anything.

Could the "version" entry in CloudronManifest.jsonbe the culprit?

fbartels

@necrevistonnezr said in Bitwarden - Self-hosted password manager:

Could the "version" entry in CloudronManifest.jsonbe the culprit?

No, at least not from my experience. It always depends from where you installed an app previously. So for example when you initially installed an app from the official appcenter you can not easily update it with a locally build app. To make it recognize an existing app you can add the --app parameter to the install command.

So e.g. cloudron update --app bit

But make sure that the applications are actually compatible with each other.

necrevistonnezr

Still gettin errors:

osboxes@osboxes:~/bitwardenrs-app$ cloudron update --app bit
Will update app at location bit
 => Waiting for app to be updated 
 => Starting ... ...
 => Backup - Snapshotting app bit.mydomain.de ..
 => Backup - undefined 
 => Downloading image ...........................................
App update error: Installation failed: undefined

osboxes@osboxes:~/bitwardenrs-app$ sudo cloudron update --app bit
Will update app at location bit
Failed to update app: 409 message: Not allowed in error state

fbartels

@necrevistonnezr it seems to fail at downloading the image, so it has nothing to do with the app per se.

Can you also post the output of cloudron build?

Maybe it could also help to remove the existing app before (but since it fails at downloading I would doubt that).

necrevistonnezr

Output of cloudron build:

Building locally as necrevistonnezr/bitwardenrs:20191210-094936-34576695f

Sending build context to Docker daemon  114.2kB

Step 1/28 : FROM "bitwardenrs/server:1.13.0-alpine" as bitwarden
 ---> c0f785714c65
Step 2/28 : FROM cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
 ---> 534bd0efda10
Step 3/28 : ENV ROCKET_ENV "staging"
 ---> Using cache
 ---> 08e348a2d671
Step 4/28 : ENV ROCKET_PORT=3000
 ---> Using cache
 ---> 4f829684eb90
Step 5/28 : ENV ROCKET_WORKERS=10
 ---> Using cache
 ---> 4c341fbb8b34
Step 6/28 : ENV DATA_FOLDER=/app/data
 ---> Using cache
 ---> 624de75507eb
Step 7/28 : ENV CONFIG_FILE=/app/data/config.json
 ---> Using cache
 ---> df63ce28a824
Step 8/28 : ENV SIGNUPS_ALLOWED=false
 ---> Using cache
 ---> 98489eda2ecf
Step 9/28 : ENV INVITATIONS_ALLOWED=true
 ---> Using cache
 ---> 363bd3b89949
Step 10/28 : ENV WEBSOCKET_ENABLED=true
 ---> Using cache
 ---> c3ab1f3b150c
Step 11/28 : ENV DISABLE_ADMIN_TOKEN=true
 ---> Using cache
 ---> 57d590406e2c
Step 12/28 : RUN mkdir -p /app/data
 ---> Using cache
 ---> bf796d6b68b4
Step 13/28 : VOLUME /app/data
 ---> Using cache
 ---> af0388a6c7c5
Step 14/28 : EXPOSE 80
 ---> Using cache
 ---> c4e5fc4eef9c
Step 15/28 : EXPOSE 3012
 ---> Using cache
 ---> 0d3be2006979
Step 16/28 : RUN rm /etc/apache2/sites-enabled/*
 ---> Using cache
 ---> 128658526e5f
Step 17/28 : RUN sed -e 's,^ErrorLog.*,ErrorLog "|/bin/cat",' -i /etc/apache2/apache2.conf
 ---> Using cache
 ---> 460b63a85e66
Step 18/28 : RUN a2disconf other-vhosts-access-log
 ---> Using cache
 ---> b660416c4b47
Step 19/28 : COPY apache.conf /etc/apache2/sites-enabled/bitwarden.conf
 ---> Using cache
 ---> 380066c29b0c
Step 20/28 : RUN a2enmod ldap authnz_ldap proxy proxy_http proxy_wstunnel rewrite
 ---> Using cache
 ---> 5d85bcdb4449
Step 21/28 : COPY --from=bitwarden /web-vault /app/code/web-vault
 ---> Using cache
 ---> 8c8e6cd0a79a
Step 22/28 : COPY --from=bitwarden /bitwarden_rs /app/code/
 ---> Using cache
 ---> 23aa34133bc8
Step 23/28 : COPY --from=bitwarden /Rocket.toml /app/code/
 ---> Using cache
 ---> 16d854c4cdb4
Step 24/28 : ADD supervisor/ /etc/supervisor/conf.d/
 ---> Using cache
 ---> 94e6be8b3e39
Step 25/28 : RUN sed -e 's,^logfile=.*$,logfile=/run/supervisord.log,' -i /etc/supervisor/supervisord.conf
 ---> Using cache
 ---> a4b630549d9e
Step 26/28 : WORKDIR /app/code
 ---> Using cache
 ---> ac66a3410991
Step 27/28 : COPY start.sh /app/code/start.sh
 ---> Using cache
 ---> 8fee6c91fd4a
Step 28/28 : CMD [ "/app/code/start.sh" ]
 ---> Using cache
 ---> ebd0cc6480c9
Successfully built ebd0cc6480c9
Successfully tagged necrevistonnezr/bitwardenrs:20191210-094936-34576695f

[1mPushing necrevistonnezr/bitwardenrs:20191210-094936-34576695f[22m
The push refers to repository [docker.io/necrevistonnezr/bitwardenrs]
59ca39a8baf6: Preparing
d20566396bfd: Preparing
426f40b89686: Preparing
351495e80404: Preparing
205c5dee79e1: Preparing
4f9345d26f82: Preparing
ffd05eeb91b1: Preparing
5418b55c5d1d: Preparing
92cad9313b91: Preparing
0ea137c0c63c: Preparing
16ef7d4b2f8e: Preparing
f8a2b79c8722: Preparing
5648d21d9467: Preparing
bfe34f2cfbd0: Preparing
83a42f6af455: Preparing
f81e4eb4d80a: Preparing
cd78fba29389: Preparing
5662a07238a1: Preparing
8d7ea83e3c62: Preparing
6a061ee02432: Preparing
f73b2816c52a: Preparing
6267b420796f: Preparing
a30b835850bf: Preparing
5648d21d9467: Waiting
bfe34f2cfbd0: Waiting
83a42f6af455: Waiting
f81e4eb4d80a: Waiting
cd78fba29389: Waiting
4f9345d26f82: Waiting
5662a07238a1: Waiting
8d7ea83e3c62: Waiting
6a061ee02432: Waiting
ffd05eeb91b1: Waiting
5418b55c5d1d: Waiting
f73b2816c52a: Waiting
6267b420796f: Waiting
92cad9313b91: Waiting
0ea137c0c63c: Waiting
16ef7d4b2f8e: Waiting
f8a2b79c8722: Waiting
a30b835850bf: Waiting
351495e80404: Layer already exists
205c5dee79e1: Layer already exists
d20566396bfd: Layer already exists
426f40b89686: Layer already exists
59ca39a8baf6: Layer already exists
4f9345d26f82: Layer already exists
ffd05eeb91b1: Layer already exists
0ea137c0c63c: Layer already exists
16ef7d4b2f8e: Layer already exists
f8a2b79c8722: Layer already exists
92cad9313b91: Layer already exists
5418b55c5d1d: Layer already exists
5648d21d9467: Layer already exists
bfe34f2cfbd0: Layer already exists
f81e4eb4d80a: Layer already exists
5662a07238a1: Layer already exists
cd78fba29389: Layer already exists
8d7ea83e3c62: Layer already exists
83a42f6af455: Layer already exists
6a061ee02432: Layer already exists
f73b2816c52a: Layer already exists
6267b420796f: Layer already exists
a30b835850bf: Layer already exists
20191210-094936-34576695f: digest: sha256:ab443082901c6beac8d3e222448e20436b5e4d51c380bc2146f1f8d868ce06d4 size: 5114

And how do I get past the 409 message: Not allowed in error state?

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Solved Bitwarden - Self-hosted password manager

Commands run on Cloudron server.