Bitwarden - Self-hosted password manager
-
@fbartels I'm not sure if something is different in my configuration... but if I visit my site at
bitwarden.example.com/adminfrom a private window with no cookies, I'm not getting a basic auth prompt.Is that working for you?
@iamthefij yes, http auth is working in my branch.
I think I should add that I am not using the app for my production bitwarden install. This is still running on a different system.
I have also seen quite some weird behaviour in regards to the mail integration, but did not yet have the time or interest in really digging into it.
-
-
@d19dotca Apps that are not published yet have to be built by hand. It's easy to build though:
git clone <app repo> npm install -g cloudron-cli cloudron build # this will ask your cloudron.io login cloudron install # this will ask you for your cloudron's login -
@d19dotca Apps that are not published yet have to be built by hand. It's easy to build though:
git clone <app repo> npm install -g cloudron-cli cloudron build # this will ask your cloudron.io login cloudron install # this will ask you for your cloudron's login -
@murgero It's available to anyone, using the cli tool (https://cloudron.io/blog/2017-03-08-cli-part2.html)
-
@murgero It's available to anyone, using the cli tool (https://cloudron.io/blog/2017-03-08-cli-part2.html)
-
Started digging back into email sending and got closer.
I just noticed that the Cloudron docs say that the STARTLS uses a self signed cert, which makes sense given that the host I'm using is
mailand notmy.example.com.So I switched back to unencrypted and enabled more verbose logging. Ended up with:
Jul 25 16:34:22 [2019-07-25 16:34:22][rocket::rocket][INFO] POST /admin//invite/ application/json: Jul 25 16:34:22 [2019-07-25 16:34:22][_][INFO] Matched: POST /admin/invite (invite_user) Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp::client][DEBUG] connecting to 172.18.0.6:2525 Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp::client][DEBUG] Read: 220 my.example.com ESMTP Haraka/2.8.23 ready<CRLF> Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp][INFO] connection established to 172.18.0.6:2525 Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp::client][DEBUG] Wrote: EHLO 90859b46-d863-4609-a83a-79c5f010254c<CRLF> Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp::client][DEBUG] Read: 250-my.example.com Hello 90859b46-d863-4609-a83a-79c5f010254c.cloudron [172.18.0.12]Haraka is at your service.<CRLF>250-PIPELINING<CRLF>250-8BITMIME<CRLF>250-SMTPUTF8<CRLF>250-SIZE 26214400<CRLF>250 AUTH LOGIN PLAIN<CRLF> Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp][DEBUG] server my.example.com with {Authentication(Login), Authentication(Plain), SmtpUtfEight, EightBitMime} Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp][INFO] No supported authentication mechanisms available Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp::client][DEBUG] Wrote: MAIL FROM:<bitwarden.app@example.com> BODY=8BITMIME SMTPUTF8<CRLF> Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp::client][DEBUG] Read: 550 Mail from domain 'example.com' is not allowed from your host<CRLF> Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp::client][DEBUG] Wrote: QUIT<CRLF> Jul 25 16:34:22 [2019-07-25 16:34:22][lettre::smtp::client][DEBUG] Read: 221 my.example.com closing connection. Have a jolly good day.<CRLF> Jul 25 16:34:22 [2019-07-25 16:34:22][bitwarden_rs::error][ERROR] Error sending email. Mail from domain 'example.com' is not allowed from your host Jul 25 16:34:22 [2019-07-25 16:34:22][_][INFO] Outcome: Success Jul 25 16:34:22 172.18.0.1 - User [25/Jul/2019:16:34:22 +0000] "POST /admin/invite/ HTTP/1.1" 400 990 "https://bitwarden.example.com/admin" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0" Jul 25 16:34:22 [2019-07-25 16:34:22][_][INFO] Response succeeded. Jul 25 16:34:24 [Thu Jul 25 16:34:24.254775 2019] [access_compat:error] [pid 32] [client 172.18.0.1:37122] AH01797: client denied by server configuration: proxy:http://127.0.0.1:3000/admin/So this is definitely more descriptive. Seems like the server is rejecting the request.
-
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 ] -
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 ]Tried with the LTS node version today - still the same error "Domain is in use". Anyone have an idea why?
-
@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 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).
@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.
-
@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.
@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.
--
Dustin Dauncey
www.d19.ca -
@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.
@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-selfsignedI was able to build and update the bitwarden... -
@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-selfsignedI was able to build and update the bitwarden...@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.
-
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, includingAuthentication(Plain), which is whatswacksuses when successfully sending on the same port. However,lettrerefuses 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
lettreis trying to validate the certificate, but that certificate is invalid.A patch to Bitwarden_rs may be required to tell
lettreto 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.
-
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, includingAuthentication(Plain), which is whatswacksuses when successfully sending on the same port. However,lettrerefuses 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
lettreis trying to validate the certificate, but that certificate is invalid.A patch to Bitwarden_rs may be required to tell
lettreto 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.
?