Bitwarden - Self-hosted password manager

jdaviescoates

@necrevistonnezr given this @fbartels app works and is the most requested app, and the release of Cloudron 5 out of the way, and the goal for this year seems to be to get lots more apps released, I'm left wondering what is holding up getting this into the app store @girish @nebulon?

will

@necrevistonnezr I know you've talked about it in the past, do you have the thread where there are instructions on how to install it? DO I add that URL as a private git repo? Never did any custom app stuff before (well I tried and failed)

necrevistonnezr

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

@necrevistonnezr I know you've talked about it in the past, do you have the thread where there are instructions on how to install it? DO I add that URL as a private git repo? Never did any custom app stuff before (well I tried and failed)

Install & run Docker, it will ask you to log in or create a Docker account
Keep the Docker app / service running
git clone https://git.cloudron.io/fbartels/bitwardenrs-app and cd bitwardenrs-app
cloudron build(that's assuming you have installed cloudron cli via npm) - it will ask you for your cloudron credentials, and ask for your Docker repository, which should be set to public during the installation (makes it easier from my experience), e.g. in the form Docker_Username/bitwarden_rs
cloudron install: it will ask for the domain to install to, e.g. bit.domain.tld

If you update, it's pretty much the same, just git pullin the app directory, cloudron build, and then cloudron update --app bit.domain.tld

will

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

cloudron build

Ok went through the steps.

installed docker, registered and made an empty public repo
On my linux vm I got docker up and running
Cloned that repo to local dir
Ran Cloudron build inside repo folder
Seemed to build but then asked if I was logged into docker?
Logged into docker and cloudron on the CLI and tried again.
CLI seemed to try to get at a repo at docker.io, but my repo is at hub.docker.com

Sorta installed, visible in cloudron error message in cloudron:

If a configuration, update, restore or backup action resulted in an error, you can retry the task.

An error occurred during the install operation: Not found: Unable to pull image willrimmer/bitwarden_rs:20200320-035449-643626a03. message: (HTTP code 404) unexpected - manifest for willrimmer/bitwarden_rs:20200320-035449-643626a03 not found statusCode: 404

Let me know if I'm understanding the flow correctly.

Clone from github locally.
Package up a Cloudron ready docker container and push to Docker Hub
Cloudron grabs and deploys from Docker Hub(?)

girish

@will The docker image didn't get pushed for some reason. I don't see it here - https://hub.docker.com/r/willrimmer/bitwarden_rs . Just do a cloudron build again. Do you see it push ?

necrevistonnezr

BTW, when looking for the newest Docker releases, this site https://docker-hub-rss.now.sh and in particular this feed
https://docker-hub-rss.now.sh/bitwardenrs/server.atom is ery helpful...

will

@girish Woohoo! It worked!

01 Installing the App
$ sudo docker login
$ sudo cloudron login my.example.com
$ git clone https://git.cloudron.io/fbartels/bitwardenrs-app
$ cd bitwardenrs-app
$ sudo cloudron build
Enter repository (e.g registry/username/com.github.bitwardenrs): username/dockerhub-repo
$ sudo cloudron install -l bitwarden.example.com

02 Updating the App
$ git pull https://git.cloudron.io/fbartels/bitwardenrs-app
$ sudo cloudron build
$ sudo cloudron update --app bitwarden.example.com

03 Configuring the App
Go to bitwarden.example.com/admin to configure.

I can add users manually, is there a way to tie this Cloudron LDAP?
Thanks!

iamthefij

Where does this stand on becoming "official" in some way? I'm still running Bitwarden off Cloudron myself as my Cloudron instance is hosting the version I'm using for development.

iamthefij

@will Yes, you can use LDAP if you use the version I published.

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

Updated to the latest version. ~~I haven't updated to the latest versions of Bitwarden just yet though. I'll give that a go now.~~

Edit: It looks like Bitwarden_rs was updated to use a newer base image for building it's binaries. That means that when the binary used in the MySQL image is built, it's compiled against a newer version of libmariadb. It doesn't look like the Cloudron base image has been updated in a year, so I'm unable to just bump the version in the single-stage Dockerfile in my repo. However, I also have a multi-stage Dockerfile that will compile Bitwarden_rs from source against whatever version of libmariadb that is present. This should work but takes more time to build so I'm letting that run right now. I'll update when it's done. Edit: It's done!

Related, but kind off topic: Can we get an update to the Cloudron base? How will those be handled in an ongoing basis since apps are pinned (as they should be) to a particular base? I imagine there have been security updates in the last year.

jimcavoli

@iamthefij An update to the Cloudron base image gets brought up every few months for the last year or so. The most recent official mention of an updated base image was by @nebulon last August but it there's been a pin stuck in that with the aggressive releases as of late - perhaps this and other apps getting updated and looking to move forward soon will help un-stick that again, especially since it's been about a year since 1.0.0 dropped.

cc @girish for a more definitive idea

will

@iamthefij How do I build the new image that ties in LDAP? (Note: I'm not a dev, just a security monkey/sysadmin. Even getting it installed like I did was a learning experience!)

girish

@jimcavoli Now with 5.x out, I think it's time to bring out a new base image. Still working on the blog post and newsletter, so after that.

@will Bitwarden server never sees any user password and all encryption is done client side (please see https://github.com/dani-garcia/bitwarden_rs/pull/677#issuecomment-545081380 and the full thread). For this reason, one can only implement a system where LDAP users can be automatically added into the bitwarden db and then sent an email invite. @iamthefij has automated the LDAP sync and invitation flow for Cloudron LDAP. Note that, the users have to use the invitation to sign up and setup a master password (which is totally independent of Cloudron password).

In short, you can just add/invite users manually into bitwarden if you don't have that many users. There is no real LDAP sign in.

iamthefij

@will the Readme should contain the details you need. It also includes an explanation on how the LDAP integration functions (as @girish said, it's not like most apps due to the client side encryption model used in Bitwarden).

If you're familiar with building a Cloudron app, you should be able to build as normal. The compiling of the binary is handled within the Dockerfile itself by leveraging multi-stage bulds.

will

@iamthefij Just tried to build using the same steps I used for the fbartels version and got this error:

Sending build context to Docker daemon 138.8kB
Step 1/31 : FROM "bitwardenrs/server-mysql:1.13.1" as bitwarden
1.13.1: Pulling from bitwardenrs/server-mysql
8ec398bc0356: Pull complete
e4a2de8034fa: Pull complete
fd9088357d3d: Pull complete
8801aa831b23: Pull complete
dd84a9fe1d76: Pull complete
d47afa82b986: Pull complete
5d95e292b0e0: Pull complete
Digest: sha256:8d95d8f636c4bb4dc70ee6c3b1a9e32a63d19bc634c2ea3d1b6a8907b59945c9
Status: Downloaded newer image for bitwardenrs/server-mysql:1.13.1
---> adaef5949bab
Step 2/31 : FROM "vividboarder/bitwarden_rs_ldap:alpine" as bitwarden_ldap
alpine: Pulling from vividboarder/bitwarden_rs_ldap
c9b1b535fdd9: Pull complete
08dbcf01e393: Pull complete
8e8b8ccc4315: Pull complete
Digest: sha256:4578c4cdfe93b52cf5d9406d2bf6cf63ed073fceec7e11ea1ede33fbebbb755d
Status: Downloaded newer image for vividboarder/bitwarden_rs_ldap:alpine
---> 630a6d6f04a7
Step 3/31 : FROM cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
---> 534bd0efda10
Step 4/31 : RUN apt-get update && apt-get install -y --no-install-recommends libmariadbclient-dev && rm -fr /va
r/lib/apt/lists/*
---> Running in 3f31137a8125
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:5 http://archive.ubuntu.com/ubuntu bionic/universe Sources [11.5 MB]
Get:6 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1344 kB]
Get:7 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages [13.5 kB]
Get:8 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [11.3 MB]
Get:9 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [186 kB]
Reading package lists...
E: Release file for http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease is not valid yet (invalid for ano
ther 8h 46min 35s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease is not valid yet (invalid for anoth
er 8h 47min 33s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/bionic-backports/InRelease is not valid yet (invalid for ano
ther 8h 48min 53s). Updates for this repository will not be applied.
The command '/bin/sh -c apt-get update && apt-get install -y --no-install-recommends libmariadbclient-dev && rm
-fr /var/lib/apt/lists/*' returned a non-zero code: 100
child_process.js:669
throw err;
^

Error: Command failed: docker build -t willrimmer/bitwarden_rs:20200325-101241-841579f4c -f Dockerfile /mnt/c/Users/w
ill/Cloud/Code/Git/bitwardenrs-app
at checkExecSyncError (child_process.js:630:11)
at execSync (child_process.js:666:15)
at buildLocal (/usr/local/lib/node_modules/cloudron/src/build-actions.js:180:5)
at Command.build (/usr/local/lib/node_modules/cloudron/src/build-actions.js:325:9)
at Command.listener (/usr/local/lib/node_modules/cloudron/node_modules/commander/index.js:370:29)
at Command.emit (events.js:311:20)
at Command.parseArgs (/usr/local/lib/node_modules/cloudron/node_modules/commander/index.js:892:12)
at Command.parse (/usr/local/lib/node_modules/cloudron/node_modules/commander/index.js:642:21)
at Object.<anonymous> (/usr/local/lib/node_modules/cloudron/bin/cloudron:245:9)
at Module._compile (internal/modules/cjs/loader.js:1158:30) {
status: 100,
signal: null,
output: [ null, null, null ],
pid: 3496,
stdout: null,
stderr: null

Checking the readme now

will

@girish Got it, makes sense.

iamthefij

@will Strange. It looks like you're getting some validation issue from bionic-* for some reason. Possibly the clocks are off. Maybe try again? That's not specific to this project.

It looks like you could reproduce with an new Dockerfile below, or just rebuild the existing one as caching should be in place now.

FROM cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
RUN apt-get update

Does it work now? If not, check your system clock and timezone.

will

@iamthefij Ooooh I'm running this from a Fedora WSL 2 VM, does the Cloudron build have Ubuntu dependencies?

will

Interesting note:
I was using Ubuntu on Windows Subsystem for Linux last night. I performed the following steps:
01 Installing the App
$ sudo docker login
$ sudo cloudron login my.example.com
$ git clone https://git.cloudron.io/fbartels/bitwardenrs-app
$ cd bitwardenrs-app
$ sudo cloudron build
Enter repository (e.g registry/username/com.github.bitwardenrs): docker-hub-username/docker-hub-public-repo
$ sudo cloudron install
Location: bitwarden.example.com

After that the apps worked in Cloudron, worked great!

Today I uninstalled the app, and ran through the same steps on a Fedora WSL box, the app deploys, but it seems to not be serving anything. I checked the logs and found this:
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.13. Set the 'ServerName' directive globally to suppress this message
Everything else looks good with the startup of the container. Thoughts?

~~If Fedora isn't a supported dev enviroment, I'll swap back over to Ubuntu. Thanks guys!~~

EDIT: It was DNS propagation with this issue! It's always DNS....

will

Devs,
What's keeping bitwarden out of the store? Been running the fbartels version all day with no issues that were not my own fault.
As seemless as any other app that doesn't tie in with Cloudron SSO/LDAP.

girish

@will Mostly, we are just super short on time To release an app, we need to test the package, write docs, write tests, make sure updates work, make sure we understand packaging, all so that we can support it. Cloudron customers also ask us many app related questions so we have to be in a position to (reasonably) answer them.

Of course, we can just publish the app and skip all the above. I understand there is a need to "just publish" and we have a great bunch of early adopters here who will put up with all the above. I just spoke to @nebulon about this, we will get unstable package for bitwarden shortly without any of the above.

iamthefij

@will just a note, I don't believe fbartels version supports a using a dump for backing up the database. This means that if the backup is taken while the db is in a transaction, it could be corrupted.

Bitwarden_rs now supports an admin API for making sqlite backups, but does not have any cron embedded. Similar to the way the LDAP sync tool works, an additional script could be added to periodically make dumps of the sqlite database so that it can be properly backed up.

Instead, the version I have is using MySQL, which leverages the native Cloudron backup and restore functionality.

That and the LDAP invite service are the real differences between the two forks. If you do not wish to use automated LDAP invites on my fork, you can select to opt out when installing. This is covered in the readme.

will

@iamthefij I just havent been able to get yours going using the steps I posted above

iamthefij

@will Which thing is failing? Building still works for me, even if I clear my cache. Make sure you do a git pull though. It looks like your build command is using the single build Dockerfile rather than the multi-phase one.

will

@iamthefij How do I use the multi stage dockerfile?

girish

It seems people are struggling to build. @iamthefij if you have your docker image public, you can just put it here. People can then install it as:

cloudron install --image <image> # run this in the repo directory

No need to build!

iamthefij

@girish good idea. Here's my build: https://hub.docker.com/r/iamthefij/cloudron-app-bitwarden

@will The multi-stage build should be default if you've pulled the latest. Dockerfile should be a symblink to the multi-stage one.

girish

thanks @iamthefij

For those looking to install this:

$ git clone ssh://git@git.cloudron.io:6000/iamthefij/bitwardenrs-app.git
$ cd bitwardenrs-app
$ cloudron install --image iamthefij/cloudron-app-bitwarden:0.3.0

Aaaannd it's running:

After installing, both my users got an invite to join bitwarden. Very cool.

jdaviescoates

@girish any reason not to have this in the app store as unstable? I'm assuming the only thing keeping for being officially released are tests need to be written etc?

yusf

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

After installing, both my users got an invite to join bitwarden

Like, automatically?

girish

@jdaviescoates Yes, tests plus making sure we can actually maintain it in the long run (for example, if everything is pinned properly in the docker file, things like that). Usually, @nebulon and also do a round of manual testing and put some basic docs before putting it in unstable.

@yusf yes, both users got the invite automatically.

jdaviescoates

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

@yusf yes, both users got the invite automatically.

I'm guessing perhaps @yusf was asking because what if you don't want to invite all users automatically?

yusf

@jdaviescoates Namesake reads my mind.

jdaviescoates

@yusf heh, I only just realised Yusf is obviously Yussef which of course is the same as Josef

iamthefij

When installing, uncheck SSO.

yusf

@iamthefij I haven't followed the thread continously but is there a specific reason for emailing all users who are granted access to the app through the SSO?

iamthefij

@yusf Yea, the Readme describe the reasoning.

There is no way to actually do true SSO without breaking the model for Bitwarden. The only thing that we can do is automatically invite users to sign up.

The Bitwarden_rs project doesn't have a way to invite without sending an email as when an SMTP server is configured, it will generate unique invite links for each user.

If you disable SSO, you only disable the auto-invite feature. You will then need to invite yourself via the Admin panel (admin token is echoed in the logs and in /app/data/admin_token). You can then invite anyone else you wish manually.

necrevistonnezr

Is there a reliable way to move from Bitwarden SQLite (fbartels build) to Bitwarden MySQL (iamthefij build) including all attachments?

will

This post is deleted!

will

@iamthefij I can't login to the admin page. It keeps saying "invalid token"
I did a fresh boot of the container, copied everything between access token= and HTTP/1.1"
access_token= copied this giberish HTTP/1.1"

Thoughts?

nebulon

Just to inform everyone here, today I've created a new gitlab project for this app package repo wise, based on @iamthefij version, however without relying on external dockerimages being mounted during app image building. The repo is at https://git.cloudron.io/cloudron/bitwardenrs

One thing I wanted to ask here is, how to deal with ldap sync. Generally this works currently by a cron job running every now and then, checking availalbe users on ldap and then will invite all users, which are not yet invited to the app instance. This has the current annoying thing, where if an admin wants to first try bitwarden on the Cloudron and does not restrict access during installation, the app will send out invites to all users. Since this is the default flow, I don't want to publish the app package like that. On the other hand I do see value in those invites being sent out at the point where the admin decides this app is good to be used.
To not delay any package release further, we could avoid this topic by packaging it first without ldap, but I wanted to collect some feedback on this here in the thread first. It would be great if you all could share your ideal flow regarding this and maybe explain the use-cases briefly.

Thanks! And even more thanks to @iamthefij for all the work done on the package already!

will

@nebulon My view is if it does not have "full" ldap, ldap should be taken out and left up to the admin to manage by hand, such as it is with other apps, like Ghost, or Monica.

iamthefij

@nebulon yea, the best for Cloudron would be a way to silently invite so only ldap users could sign up. Maybe I’ll make that suggestion over at the main project.

I feel that would make a much better experience for users and admins here.

What I did was install it scoped to only my user and then expanded the users to a group later.

d19dotca

@nebulon I'm not certain why this app would be unique in that when it's setup it just immediately sends out invites to everyone possible. Seems very strange to have it work that way.

Not sure if it's possible, but I think my ideal vision of it is that when we select an LDAP group for authentication, it will allow those users access / send an invite once they attempt the first login from an allowed group, but otherwise it would not auto-invite anybody.

And if that can't be done then I'd prefer it just be a manual invite or even "app managed" instead like Invoice Ninja or something where you don't need to have LDAP be the authenticator for the app and can manage it fully inside the app itself instead.

Hopefully I didn't misunderstand the situation and question. haha

nebulon

@d19dotca yes that would be nice to only send invites upon user login attempt, or even better to not send invites but just allow users in that LDAP group to signup normally. However currently this is not possible with the upstream app. So my suggestion is to polish the app package now without any LDAP, since it is confusing currently and just get it pulished. We can always add LDAP once the flow is more obvious and straightforwards.

d19dotca

@nebulon Ah okay, didn’t realize it was an app limitation rather than a packaging limitation. In that case then I would definitely prefer it be pushed without LDAP support (so app-managed) and we can add LDAP support at a later time when the app will allow a better workflow.

nebulon

I will lock this thread as we have published the initial app package now: https://forum.cloudron.io/topic/2372/bitwarden_rs

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