Bitwarden - Self-hosted password manager

fbartels

the Dockerfile in the git repo of bitwarden_rs makes use of multi stage building. is that already supported in cloudron build? If so then is should be trivial to adapt the last stage of the build process.

Edit: to answer myself. Cloudron currently does not seem to support multi stage docker builds.

necrevistonnezr

Has anyone made progress on this app?

FTLAUDMAN

I would love to see this app on Cloudron. It would immediately become my new password manager.

necrevistonnezr

Bitwarden now has live-sync

Live sync will instantly push changes from one Bitwarden app to all others that you may be using within a matter of seconds.

https://blog.bitwarden.com/live-sync-bitwarden-apps-fb7a54569fea?gi=2a2ca195c303

fbartels

Hi @nebulon ,

I made a few tests today since I remembered that there is a dockerImage value in CloudronManifest.json, but I am not quite sure how to use it.

My current experiment is at https://github.com/fbartels/bitwarden_rs/tree/cloudron/cloudron. It uses a new Dockerfile that uses the multi stage Dockerfile as a base and uses a Cloudron Base Image for the last stage. But it seems he does not take my dockerImage. The only way he pulls in my image is by calling cloudron install --image fbartels/bitwarden-cloudron from the commandline.

For everyone else reading this. This is up until now only a build, the app is still missing all integration pieces and won't work withing Cloudron (yet).

heliostatic

They just published their security audit (https://blog.bitwarden.com/bitwarden-completes-third-party-security-audit-c1cc81b6d33) which seems like as good a reason as any to bump this request back up.

daniel.goletz

Any news?
Or simmiliar app in development?

@fbartels How is the project going?

fbartels

@spectrely no, I had no further time to really look into this so far. Busy with other projects.

@spectrely with cloudron now on 18.04 do multi stage builds now work? You can try this with a cloudron build in the git clone'ed directory.

@fbartels Thanks for the quick reply. I'll play around and report back.

necrevistonnezr

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

@fbartels Thanks for the quick reply. I'll play around and report back.

Did you try that out?

iamthefij

LDAP support is a Work in Progress right now.

The plan is not to have it leverage LDAP for auth, but to auto invite users from LDAP so that new user registration doesn't have to be enabled.

fbartels

To answer my own question: no Cloudron still does not support multi stage builds:

08:07 $ docker build .
Sending build context to Docker daemon   7.68kB
Step 1/12 : FROM cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617: Pulling from cloudron/base
124c757242f8: Pull complete
9d866f8bde2a: Pull complete
fa3f2f277e67: Pull complete
398d32b153e8: Pull complete
afde35469481: Pull complete
5fa763ad3e3d: Pull complete
6f382df2868f: Pull complete
da8db3680a7d: Pull complete
bbf6e101d755: Pull complete
ba1148a00c9f: Pull complete
7b84d63a4591: Pull complete
Digest: sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
Status: Downloaded newer image for cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
 ---> 534bd0efda10
Step 2/12 : ENV ROCKET_ENV "staging"
 ---> Running in 68b6aa46c8fe
Removing intermediate container 68b6aa46c8fe
 ---> b5146c0012ce
Step 3/12 : ENV ROCKET_PORT=80
 ---> Running in 3ceb3ae20f44
Removing intermediate container 3ceb3ae20f44
 ---> 20f1c76798d9
Step 4/12 : ENV ROCKET_WORKERS=10
 ---> Running in fb4da112f345
Removing intermediate container fb4da112f345
 ---> 4715e7e5db66
Step 5/12 : RUN mkdir -p /app/data
 ---> Running in 080caeccf4bc
Removing intermediate container 080caeccf4bc
 ---> 3bc89f3dd8e3
Step 6/12 : VOLUME /app/data
 ---> Running in c14ec82d1d86
Removing intermediate container c14ec82d1d86
 ---> 921426c4b462
Step 7/12 : EXPOSE 80
 ---> Running in 6f8a51fa17c2
Removing intermediate container 6f8a51fa17c2
 ---> 945b85a9d2c0
Step 8/12 : EXPOSE 3012
 ---> Running in 57a9f4770437
Removing intermediate container 57a9f4770437
 ---> 29bf7e9ddc35
Step 9/12 : COPY --from=mprasil/bitwarden:1.7.0 /web-vault /app/code/web-vault
1.7.0: Pulling from mprasil/bitwarden
6ae821421a7d: Pull complete
6b62744e37c4: Pull complete
6f7d0f488d72: Pull complete
b1dac5a36400: Pull complete
f5334a919416: Pull complete
86593ec71a37: Pull complete
Digest: sha256:0d48e5b8f64d83a0d0931aba0fb559985a687b7417ceb49fb909051b0f397f47
Status: Downloaded newer image for mprasil/bitwarden:1.7.0
 ---> 8362350b2ff1
Step 10/12 : COPY --from=mprasil/bitwarden:1.7.0 /bitwarden_rs /app/code/
 ---> d6e0b6fc0c46
Step 11/12 : COPY --from=mprasil/bitwarden:1.7.0 /Rocket.toml /app/code/
 ---> e835acd7031b
Step 12/12 : CMD /app/code/bitwarden_rs
 ---> Running in 81f78757da52
Removing intermediate container 81f78757da52
 ---> 89d5017a81f4
Successfully built 89d5017a81f4
✔ ~/.../bitwarden_rs/cloudron [cloudron L|✔]
08:09 $ cloudron build
Building com.github.bitwardenrs@0.1.0

Build scheduled with id bc08173c-2af9-4f3f-a759-19d60bb45cf8
Waiting for build to begin, this may take a bit...
Step 1/12 : FROM cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
 ---> 534bd0efda10
Step 2/12 : ENV ROCKET_ENV "staging"
 ---> Using cache
 ---> c5a9b7d6ac6f
Step 3/12 : ENV ROCKET_PORT 80
 ---> Using cache
 ---> 2d22bcf6dc7d
Step 4/12 : ENV ROCKET_WORKERS 10
 ---> Using cache
 ---> 2e5e855777d5
Step 5/12 : RUN mkdir -p /app/data
 ---> Using cache
 ---> 2688a8102e91
Step 6/12 : VOLUME /app/data
 ---> Using cache
 ---> 4ee6f1df5ccf
Step 7/12 : EXPOSE 80
 ---> Using cache
 ---> 5f451061f3e1
Step 8/12 : EXPOSE 3012
 ---> Using cache
 ---> 8c5e8e7a13b4
Step 9/12 : COPY --from=mprasil/bitwarden:1.7.0 /web-vault /app/code/web-vault
Unknown flag: from
Build failed
Build failed
ERROR App could not be built due to errors above [ /usr/lib/node_modules/cloudron/src/helper.js:68:29 ]

While a standalone ``docker build .` succeeds doing it via ´cloudron build´ fails.

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

LDAP support is a Work in Progress right now.

I would say even the recently introduced admin panel is already a good step. This could be secured via http basic auth and only allowed for admins in Cloudron. The last point in the ldap sync topic was afair that this will be implemented as a standalone tool (which then will give the challenge on how to integrate both parts in the same image).

iamthefij

@fbartels The tool will likely be written as a static binary which can be downloaded and installed within the same container. Then it can be executed by Cloudron using the scheduler. Roughly the same way other periodic tasks are executed.

parhelium

Is there chance Bitwarden is going to be included in cloudron soon ?
I would like to start using it.

fbartels

Docker has recently been updated on the cloudron buildserver, which means multi stage builds and COPY --from now works within Dockerfiles.

I have a longer train ride on friday, maybe I can now make something happen with Bitwarden_rs.

fbartels

basic prototype now lives in https://git.cloudron.io/fbartels/bitwardenrs-app

cannot build it at the moment, though. since its stuck at

$ cloudron build                                                                                                                                                                                                                  
Building com.github.bitwardenrs@0.1.0

Build scheduled with id 9fcf31f1-04f9-445e-b687-79b2f7d54659
Waiting for build to begin, this may take a bit...

@girish is the backend maybe hanging?

edit: by now the build has finished

necrevistonnezr

Great that this is being worked on!

I installed the app but get the following errors:

Mar 23 10:36:17 box:shell addLogrotateConfig spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/configurelogrotate.sh add a3cda43e-541b-4edd-b8fe-c4cfb52752fb /tmp/a3cda43e-541b-4edd-b8fe-c4cfb52752fb.logrotate
Mar 23 10:27:12 => Starting bitwarden_rs
Mar 23 10:27:12 [2019-03-23 10:27:12][bitwarden_rs][ERROR] Error creating database directory
Mar 23 10:27:16 => Starting bitwarden_rs
Mar 23 10:27:16 [2019-03-23 10:27:16][bitwarden_rs][ERROR] Error creating database directory
Mar 23 10:27:19 => Starting bitwarden_rs
Mar 23 10:27:19 [2019-03-23 10:27:19][bitwarden_rs][ERROR] Error creating database directory
Mar 23 10:27:22 => Starting bitwarden_rs
Mar 23 10:27:22 [2019-03-23 10:27:22][bitwarden_rs][ERROR] Error creating database directory
Mar 23 10:27:26 => Starting bitwarden_rs
Mar 23 10:27:26 [2019-03-23 10:27:26][bitwarden_rs][ERROR] Error creating database directory
Mar 23 10:27:30 => Starting bitwarden_rs

After restarting the app it's now not responding
Tried sudo systemctl restart boxas well.

gml

Hi @fbartels

Build and install worked without problems, but i'm facing the same issue as @necrevistonnezr

Couln't really find something on the first view, but i'm not that familiar with containers. Would be great to see it running, thank you for your efforts you already made!

gml

@fbartels It works now with the fix from my colleague m4rg4sh (he submitted a pull request). Also there is a new version 1.8.0 - I just updated to it and everything looks great so far

fbartels

Thanks for the pr. I just merged it and also update the dockerfile to 1.8.0.

gml

You're welcome

I hope this pr is going to be merged into bitwarden_rs soon: https://github.com/dani-garcia/bitwarden_rs/pull/396

It would make it a lot easier for the user management. Currently registration is open to the world until you set ENV SIGNUPS_ALLOWED=false, which only makes sense after you created a first account. After setting it you could work with invites, but the invitation model sucks (you can just invite when having an Organisation or you can do it in the admin panel, but you have to set another env variable to access it and you can't save stuff there).

So currently not really usable for the normal user. As far as I understood, with the ldap integration accounts / invites will be synced for all ldap users, which is exactly what we want. I also hope the admin panel gets some love, as in my eyes the token system to log in there isn't really easy to handle. And there seems to be a problem saving the settings you set there, but that's probably a problem in the cloudron integration.

fbartels

@gml yes, the ldap invite tool would be nice. I think the best for the moment would be to slap Apache Infront of bitwarden (would be needed anyways for the websocket part) and hide the admin panel behind ldap auth (only allow admin users from within cloudron). Then invites and open registration can be disabled and admins can manually create accounts as needed.

fbartels

I've now spent a bit of time to get the admin page "properly" working. Registrations are now disabled in the app itself, but users that are in the cloudron admin group can login to /admin to create the required users.

Stuff like Websockets support (for folder notifications) is still missing, as well as automatic SMTP configuration but I would say the general app is "done".

Looking forward to feedback.

gml

Hi @fbartels

Thank you for your great work! This is definitely on a good path

Some few things I noticed:

Saving a config throws a Error saving config: IOError. I also checked with a reboot and it seems it really can't be saved right now. (also smtp wouldn't be possible without this fixed)
When accessing the admin panel when not logged into cloudron, you get a password prompt. A 403 HTTP would probably be more suitable and secure

And as a small Bonus: As the app is getting in a pretty good shape, it is time for a logo =D
here you go: https://github.com/bitwarden/brand/blob/master/icons/256x256.png

fbartels

@gml thanks. I have fixed the location of the config.json created by the admin panel. Settings can now be stored (but SMTP settings should probably be done in start.sh instead). I have also added your logo.

The password prompt is actually expected since ldap auth is used in the webserver. The only way around the prompt would be to use oauth instead, but in previous attempts (the cloud torrent app) I did not get this to run.

necrevistonnezr

Many thanks!
It's working for me. A few observations:

the invitation e-Mail did not get send as I hadn't change the SMTP settings, but once the e-Mail is on the invite list, this e-Mail can register an account
even with 1 GB of memory assigned, I get a "ran out of memory" quite often
currently the app is quite unresponsive as it's searching for favicons (as I can see from the logs)
Importing from Enpass 6 (json) worked fine for me

necrevistonnezr

Another question - how are updates done? Or will your app eventually become an "official" cloudron app?

fbartels

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

even with 1 GB of memory assigned, I get a "ran out of memory" quite often
currently the app is quite unresponsive as it's searching for favicons (as I can see from the logs)
Importing from Enpass 6 (json) worked fine for me

This probably depends quite a bit on the amount of data you throw at it. I actually started with an empty vault since password history etc would not have carried over anyways. But in my case it's easy to keep a portable version of keepass around if I need a password from the old database.

Maybe the icon caching is causing some troubles for you? You could deactivate this from the settings. Probably also a good idea to get in touch with the upstream project if they are already aware on this and if there is anything to lighten the load a bit

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

how are updates done? Or will your app eventually become an "official" cloudron app?

My idea is to have a good base so that @nebulon can make this an official app.

iamthefij

LDAP syncing is now available for bitwarden_rs. Check it out on the wiki.

Do you have your app shared on git.cloudron.io yet? If so I can help contribute.

necrevistonnezr

@iamthefij The repo is at https://git.cloudron.io/fbartels/bitwardenrs-app

iamthefij

I've got a branch where I've almost gotten LDAP syncing fully working, but invites don't seem to be working properly.

Even if I try to send an invite directly through the web interface, it just hangs. The user shows in the list, however the logs never show a success or failure response for the request. I've checked the SMTP settings and they appear to be correct. I'll keep debugging though.

https://git.cloudron.io/iamthefij/bitwardenrs-app/tree/ldap-sync

iamthefij

Got it working! Turns out I needed to enable SMTP_EXPLICIT_TLS.

Now I just have to schedule the sync task and do some cleanup. Should have a fully ready app soon.

iamthefij

Just set up the scheduler, but I'm getting weird results.

When the sync is run through the scheduler I get:

Apr 23 00:10:08 thread 'main' panicked at 'Could not authenticate with http://127.0.0.1:3000. Error { kind: Hyper(Error { kind: Connect, cause: Os { code: 111, kind: ConnectionRefused, message: "Connection refused" } }), url: Some("http://127.0.0.1:3000/admin/") }', src/bw_admin.rs:62:17

However, it runs just fine when I drop into a terminal and select the task from the dropdown and run it.

@girish I figured it would be using docker exec, and when I ssh to my server I can run it successfully using

 sudo docker exec 92ad3d37-2014-44f4-870f-25d862f57b4a sh -c '/app/code/ldap_sync.sh'

However I just dug through the source for the scheduler addon and found that it's creating a new container.

How should we access the original container via HTTP? Is there a reason this is a new container and not simply an exec?

fbartels

@iamthefij hm.. I just noticed that I see the same behaviour in bitwarden. Sending a mail does not give an error in the ui and the log states 12:09:50 - [2019-04-23 10:09:50][lettre::smtp::client][DEBUG] connecting to 172.18.0.13:2465, but no mail is actually retrieved (on the same cloudron system).

Adding SMTP_EXPLICIT_TLS on the other hand left me with a Error sending email. handshake error error when sending mails.

I am not quite sure btw about setting a token for the admin interface. this unfortunately seems required by the sync job, but in the cloudron case it complicates stuff a bit, since there is afaik no easy way to add this token somewhere where an admin without shell access can easily read it.

iamthefij

@fbartels I'm not certain it's actually required, but it is recommended.

I added it because I saw some strange behavior with the LDAP access controls. Without the Admin Token, I was somehow able to access the admin page with no auth check via a Private Browsing window. I can do some more testing and see if I can do away with the token.

For sending the email, I had set both SSL and TLS to true. Though I just realized I may have been using Mailgun as I did switch to that to rule out the Cloudron SMTP server. I'll do another test. Edit: Just verified and it works using the Cloudron SMTP server with both those settings as true.

necrevistonnezr

Bitwarden_rs 1.9.0 is out
https://github.com/dani-garcia/bitwarden_rs/releases/tag/1.9.0

nebulon

As proper database support is mentioned in https://github.com/dani-garcia/bitwarden_rs/issues/246 I think we should be waiting for a release until either MySQL or Postgres is supported. Otherwise we will end up with some migration issues from sqlite to one of the others.

iamthefij

@nebulon Why do you say that? Is there something wrong with SQLite? Or you just worried about when support is eventually added?

Any insights on the issues accessing the API from a scheduled task? It would be good to get this resolved anyway.

iamthefij

Hey @nebulon, @girish . Any ideas how I can proceed to make this work for Cloudron?

I'm happy to patch box to use exec rather than run, or provide an option, but it's unclear why the decision was made to do run in the first place.

necrevistonnezr

FYI: When you increment to build number in the Dockerfile and in CloudronManifest.json, bitwarden_rs 1.9.0 builds & installs without problems...

Maybe @fbartels can update the repo even while we're waiting for other databases being supported?

fbartels

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

Maybe @fbartels can update the repo even while we're waiting for other databases being supported?

sure. done.

iamthefij

@girish any ideas on this?

girish

@iamthefij Sorry for the delay, got caught up with Cloudron 4. Now I have the time to investigate this a bit. From what I understand, the issue is that the scheduler container is unable to access the main container via HTTP? The scheduler container is supposed to be spawned in the same networking namespace and one is supposed to be able to directly access http://localhost:port. If that doesn't work, it's a bug. Let me test this and get back shortly.

girish

@iamthefij So, there is no way right now to reach out to the parent app container from the cron container. We used to use exec before but we removed it because there was actually no way to clean/delete exec containers (not sure if they have fixed this now). Those exec containers will basically hang around, so for a scheduler this means a new container keeps getting created and just accumulates garbage. IIRC, there was also a case where these scheduler containers were doing processing with files using /tmp and /run as scratchpads and then they mistakenly delete files of the parent container. This led me to change it to just spawn a completely new container. Finally, this also helps us in multi-host setups where the scheduler container can run anywhere (exec requires same pod).

I will try to make a fix tomorrow where the scheduler containers can somehow get to the app container (I guess injecting the hostname of the app container as env var will suffice).

Also, any reason why the "syncing" is not part of the main bitwarden_rs binary itself? That way the scheduler can just call bitwarden_rs ldap-sync instead of doing a http call?

iamthefij

@girish

We used to use exec before but we removed it because there was actually no way to clean/delete exec containers (not sure if they have fixed this now). Those exec containers will basically hang around, so for a scheduler this means a new container keeps getting created and just accumulates garbage.

I'm not sure I follow. Using docker run actually creates a new container by default. That is unless the --rm option is added. If added, it will remove the container after running. This is actually what Cloudron appears to do today.

In contrast, docker exec doesn't create any new container. It runs a process within an existing container. There is no need to clean up any containers after execution.

If the issue is that poorly written cron jobs are deleting files that should not be deleted, that sounds like a bug with the app, not with box. There are legitimate reasons to want to access the same filesystem. Maybe it's cleaning up logs or something. Periodically sending out files. Or, as in this case, accessing a SQLite database.

Also, any reason why the "syncing" is not part of the main bitwarden_rs binary itself?

That was a design decision by the original Bitwarden creator. Bitwarden_rs decided to follow the same convention.

That way the scheduler can just call bitwarden_rs ldap-sync instead of doing a http call?

Unfortunately, that would not get around this issue. Executing bitwarden_rs ldap-sync from a new container (created by docker run) would not have access to the same filesystem, and therefore it would write to a new SQLite database that would immediately be cleaned up.

girish

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

In contrast, docker exec doesn't create any new container. It runs a process within an existing container. There is no need to clean up any containers after execution.

If you see https://docs.docker.com/engine/api/v1.37/#operation/ContainerExec, it creates an "exec container" and returns the object id. This id is then used to start it at https://docs.docker.com/engine/api/v1.37/#operation/ExecStart. You will notice there is no API to delete this object. This object is only deleted when the main container is removed. Initially, I thought this will not be an issue but in practice, after a cron job runs more than 500 times (which is just 2-3 days), docker starts crawling and causes all sorts of strange problems. There is a github issue somewhere for this and iirc, the docker maintainers said that one should not exec too often.

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

Unfortunately, that would not get around this issue. Executing bitwarden_rs ldap-sync from a new container (created by docker run) would not have access to the same filesystem, and therefore it would write to a new SQLite database that would immediately be cleaned up.

The Scheduler run containers do have access to the filesystem/local storage by volume mounting. Otherwise, wp cron jobs cannot access wp plugins etc.

Also, regardless of above, I am working on a patch to make http access possible.

iamthefij

@girish wow! I had no clue that exec worked that way. TIL! Is there no garbage collection process? Seems strange. My host probably has a bunch of dangling execs. They’d seem like they’d be benign, but I wonder.

HTTP access would be a great way to solve this. Happy to help test or debug.

necrevistonnezr

Bitwarden_rs 1.9.1 is out
https://github.com/dani-garcia/bitwarden_rs/releases/tag/1.9.1

Fixed broken U2F in Chrome 74+
Added images to email
Updated dependencies

fbartels

I have updated the code in the git repo to 1.9.1 and also uploaded and submitted the app to the Cloudron app store. Maybe it will be shown as "untested" on Cloudrons on version 4.x.

girish

We pushed the app store release today for community apps. I will make a post tomorrow about how to get the community apps published so others can install easily.

necrevistonnezr

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

We pushed the app store release today for community apps. I will make a post tomorrow about how to get the community apps published so others can install easily.

Please include how to migrate from an existing (testing) installation, if possible. Thanks!

iamthefij

@girish any luck with getting HTTP access to work?

girish

@iamthefij Oops, this got fixed a while ago. I thought I replied to this thread. You can use the env var CLOUDRON_APP_HOSTNAME now in 4.1. For example, curl http://$CLOUDRON_APP_HOSTNAME:3000 works if http is running on port 3000.

girish

@iamthefij btw, you can set "minBoxVersion": "4.1.4" in the manifest so that people who are below that version don't try to install the app.

iamthefij

Awesome! I will give this a shot.

iamthefij

@fbartels was there a reason for moving the bitwarden image from the COPY statement to a FROM statement at the beginning? I'm picking up LDAP support again now that the hostname is available and I'm getting the binary from a published images as well.

Was it just to avoid pulling when modifying any config values?

iamthefij

@girish Hmm... it doesn't seem to be working correctly.

I'm getting:

Jun 26 17:55:25 thread 'main' panicked at 'Could not authenticate with http://8e50545e-6293-459d-8aa8-5abdb13695dc-ldap_sync:3000. Error { kind: Hyper(Error { kind: Connect, cause: Os { code: 111, kind: ConnectionRefused, message: "Connection refused" } }), url: Some("http://8e50545e-6293-459d-8aa8-5abdb13695dc-ldap_sync:3000/admin/") }', src/bw_admin.rs:62:17

It appears that the hostname is the hostname of the ldap_sync container that the cron job spawned? Is that correct? When I open a terminal for the app, it just gives the first part without ldap_sync, which seems right.

girish

@iamthefij This is indeed a bug CLOUDRON_APP_HOSTNAME is meant to be a constant and should be set to 8e50545e-6293-459d-8aa8-5abdb13695dc. For cron jobs, it is setting the env var as the hostname by mistake.

girish

@iamthefij In /home/yellowtent/box/src/docker.js at line 190,

`CLOUDRON_APP_HOSTNAME=${name}`,

Replace the above as:

`CLOUDRON_APP_HOSTNAME=${app.id}`,

Then systemctl restart box. Does that fix the problem?

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