Vaultwarden auf Raspi nur per http nicht per https erreichbar

[Piepflitze]

Ok, aktueller Status, nachdem ich die Anleitung von Heise nochmal vorgenommen habe:
1. docker compose aus dem Python-Paketmanager Pip3 zu beziehen läuft auf einen Fehler, scheint aber eh obsolet geworden zu sein, weil docker compose schon vorhanden ist. Sehe ich das richtig?
2. Die dhcpd.conf war bei mir nicht vorhanden, die habe ich dann erstellt. Ob das notwendig war, weiß ich nicht, denn eigentlich hatte ich schon eine feste IP vergeben. Sei es drum.
3. Welchen Sinn der Port 3012 in der docker-compose.yaml hat, erschließt sich mir nicht, nirgendwo steht geschrieben, dass dieser geforwarded werden soll. Kann mir das jemand sagen?
4. Der Zugriff über meine freedns-Domain geht jetzt auch per https. Das ist schon mal gut.
5. Der Zugriff über die lokale IP geht hingegen überhaupt nicht, was ich nicht logisch finde. Woran liegt das?
6. Der Zugriff auf den Admin-Bereich scheint grundsätzlich möglich zu sein, gelingt mir aber nicht. Es werden ja Benutzerdaten in der Anleitung erzeugt und mit Hash-Wert in der docker-compose.yaml hinterlegt. Hab jetzt zweimal neue Zugangsdaten erzeugt um Dummheit und Tippfehler auszuschließen. Anschließend natürlich den Container neu composed. Das Anmeldefenster ist nicht wegzubekommen, also schließe ich auf nicht akzeptierte Zugangsdaten. Im Docker Log steht nichts geschrieben. Und nun?
7. Anmeldung an Vaultwarden... vielleicht sehe ich das falsch, aber auch bei einer lokalen Installation von Bitwarden oder eben Vaultwarden muss man sich mit seinem Bitwarden-Konto anmelden. Da bekomme ich doch glatt die Fehlermeldung, dass Benutzername oder Passwort falsch sein. Genau diese Daten funktionieren aber in der Windows-App. Wo liegt mein Denkfehler?

 

[crashbandicot]

Port 3012

We intend to remove the custom Websocket implementation currently included in Vaultwarden.
This implementation uses a separate port (3012) which you needed to configure correctly into your reverse proxy for Websocket notifications to work.

https://github.com/dani-garcia/vaultwarden/discussions/4023

 

[Piepflitze]

Shi*, das hätte ich auch selbst finden können. Danke!

Ich setze mich jetzt mal an das Update von Vaultwarden und Traefik und schaue welchen Effekt das hat.

Edit: Ist der Hash eines Passworts nicht immer gleich? Ich habe ein Passwort nach folgendem Befehl generiert:
htpasswd -nb user password\<br> | sed -e s/\\$/\\$\\$/g

Aber bei jeder Wiederholung ist der Hash anders. Ist das richtig?

 

[h00bi]

Wenn du es mit npm nicht hin bekommst, lass die Finger von traefik.

Poste lieber mal Screenshots der Proxy
Host Einstellungen aus npm.
Beliebter Fehler ist z.b. die Weiterleitung auf HTTPS statt HTTP

Ergänzung (Gestern um 13:06)

5. Der Zugriff über die lokale IP geht hingegen überhaupt nicht, was ich nicht logisch finde. Woran liegt das?

Über die IP geht eben kein HTTPS

Ergänzung (Gestern um 13:08)

oder eben Vaultwarden muss man sich mit seinem Bitwarden-Konto anmelden

Vaultwarden weiß nichts von deinem Bitwarden Konto in der Bitwarden Cloud.
Im Client musst du daher auch umstellen auf "selbst gehostet" und dann mit den Zugangsdaten deines vaultwarden Users anmelden.
Der sollte nicht der Admin User sein.

 

[RedPanda05]

mal eine kategorische Frage, warum willst du eigentlich einen Vaultwarden exposen? Du könntest auch mit einem VPN arbeiten und wenn du außerhalb bist, kannst du durch den cache der Bitwarden App auch auf deine PW zugreifen? (Kein Angriff, nur interessehalber)

 

[Piepflitze]

@h00bi:
=> Traefik läuft jetzt scheinbar, NPM ist insofern nicht mehr drauf. Greife jetzt per https zu
=> Und warum geht über die IP kein https?
=> Hm. Ich hatte es bisher so verstanden, dass ich auch bei selfhosting ein "online-Konto" von Bitwarden brauche, weil es eben nur darüber die Pläne gibt. Ich wusste nicht, dass das quasi komplett ohne "Bitwarden-Bindung" geht.

@RedPanda05: Es gibt ja an anderer Stelle zahlreiche Diskussionen zum Thema SSL vs. VPN. Daraus habe ich mitgenommen, dass das Sicherheitsniveau bei VPN nicht höher ist, weil sich im Prinzip die Verschlüsselung nicht unterscheidet. Mit VPN mache ich im Ernstfall die ganze Kiste auf und nicht nur den PI. Deswegen ist für mich das Exposen des Pi am Ende risikoärmer.
Ich hab auch darüber nachgedacht, wie häufig ich Änderungen an den Datensätzen vornehme, wenn ich nicht im Lan bin und ob ich nicht damit leben kann, wenn es dann einen Versatz gibt. Zwei Punkte sprechen dagegen:
1. Familienuser, die vielleicht einmal die Woche im Lan sind
2. Soweit ich gelesen habe, keine Änderung an Datensätzen ohne Verbindung zum Tresor.

 

[RedPanda05]

Ach ok verstehe.

Wenn ich mich recht entsinne, geht https mit ip schon, da aber das Zertifikat auf die Domain ausgestellt ist, meckert der Browser.

 

[h00bi]

Und warum geht über die IP kein https?

Weil vaultwarden ohne Extras kein HTTPS kann. Damit Leute vaultwarden nicht per HTTP betreiben, weil sie keine Ahnung von Zertifikaten haben, hat man http über IP absichtlich kastriert.
Du wirst vom Entwickler quasi gezwungen HTTPS über ein Zertifikat zu nutzen als Schutz vor Faulheit.

Ergänzung (Gestern um 14:09)

zahlreiche Diskussionen zum Thema SSL vs. VPN. Daraus habe ich mitgenommen, dass das Sicherheitsniveau bei VPN nicht höher ist, weil sich im Prinzip die Verschlüsselung nicht unterscheidet.

Der Webdienst von vaultwarden wird aktiv von einer großen Community gepflegt.
Der Dienst ist dazu gedacht ins Internet gestellt zu werden.

Das ist bei vielen Diensten anders. Zudem hat vaultwarden 2FA Integration und erzwingt ein halbwegs sicheres Passwort. Bruteforce Schutz ist afaik ebenfalls integriert. Auch das ist bei vielen Services anders.
Zudem muss man für den Zugriff deine Domain + ggf. Subdomain kennen, da über die IP keine Antwort kommt.

Ein stupider FTP Server hat das z.b. nicht, deswegen sollte man diesen auch niemals ohne VPN oder ohne fail2ban öffentlich erreichbar schalten

 

[Piepflitze]

Weil vaultwarden ohne Extras kein HTTPS kann. Damit Leute vaultwarden nicht per HTTP betreiben, weil sie keine Ahnung von Zertifikaten haben, hat man http über IP absichtlich kastriert.

Ich hab über den Zugriff via IP geredet, nicht über den Verzicht auf HTTPS. Auch mit HTTPS komme ich nicht über die IP auf den Vault. Natürlich passt das Zertifikat nicht zur IP. Über HTTP kommt ein 404, über HTTPS toter Mann. Das finde ich nicht logisch, weil die Fritzbox ja im Prinzip auch nichts anderes macht, als den (externen) traffic auf die Maschine zu leiten. Warum nicht auch beim internen?

Der Webdienst von vaultwarden wird aktiv von einer großen Community gepflegt.
Der Dienst ist dazu gedacht ins Internet gestellt zu werden.

Das ist bei vielen Diensten anders. Zudem hat vaultwarden 2FA Integration und erzwingt ein halbwegs sicheres Passwort. Bruteforce Schutz ist afaik ebenfalls integriert. Auch das ist bei vielen Services anders.
Zudem muss man für den Zugriff deine Domain + ggf. Subdomain kennen, da über die IP keine Antwort kommt.

Ein stupider FTP Server hat das z.b. nicht, deswegen sollte man diesen auch niemals ohne VPN oder ohne fail2ban öffentlich erreichbar schalten

Sorry, aber ja und? Die Frage war doch, warum ich Vaultwarden von extern vie HTTPS-Verbindung statt über VPN erreichen will. Ich habe doch nicht VPN generell in Frage gestellt. Du kannst mich gerne korrigieren, aber in Bezug auf den Vaultwarden ist die HTTPS-Verbindung nicht weniger sicher als VPN, beim Durchbruch der Verschlüsselung ist VPN aber tendenziell folgenreicher. Und HTTPS reicht vom "Funktionsumfang", VPN würde mir keinen Mehrwert bieten. Oder reden wir gerade aneinander vorbei?

Neue Frage, weil ich nach wie vor an der Anmeldung für den Admin-Bereich scheitere:
Ist der Hash eines Passworts nicht immer gleich? Ich habe ein Passwort nach folgendem Befehl generiert:
htpasswd -nb user password\<br> | sed -e s/\\$/\\$\\$/g

Aber bei jeder wiederholten Ausführung dieses Befehls ist der Hash anders. Ist das richtig?

 

[h00bi]

Der Hash ist jedes Mal unterschiedlich, sonst hätte jeder, der dieser Anleitung folgt das gleiche Admin Token.
Das wäre fatal!
Dieser Guide ist mittlerweile überholt, das Admin Token im Klartext als env variable abzulegen wurde von den Entwicklern als unsicher eingestuft.

 

[Piepflitze]

Es geht nicht um den Admin-Token sondern um die Anmeldedaten, die vor dem Admin-Token abgefragt werden sollen.