Bitwarden: Neue Selfhost-Version

[Kachelkaiser]

Hallo

Habe gerade das hier gelesen:

https://stadt-bremerhaven.de/bitwarden-unified-soll-das-selbsthosten-vereinfachen/amp/

kurz: es gibt jetzt eine offizielle Selfhost Variante namens Bitwarden Unified, die wesentlich einfacher zu installieren sein soll.

Hier die offizielle Doku

https://bitwarden.com/de-DE/help/install-and-deploy-unified-beta/

Hat das schon jemand ausprobiert?

 

[Thonav]

Ja, Du übernimmst das jetzt gleich und berichtest uns

 

[EDvonSchleck]

Ich sehe da keinen Vorteil. Gegenüber Vaultwarden.

Zum einen benötigt man eine Lizenz für bestimmte Sachen. Zum anderes, was soll denn einfacher sein?
Noch einfacher geht es wohl kaum als jetzt. Man gibt max. 2 Ordner und Port frei und der Rest ist bereits in Vaultwarden incl.
Der ganze Beitrag ist nichtssagend. Dort sind die Kommentare informativer als der Beitrag selbst.

Warum man für Bitwarden bis zu 11 Container braucht, ist mir schleierhaft. Für einen Normaluser reicht 1 Container (Vaultwarden) aus. Reverseproxy und Datenbank (Sqlite) bringt die Synology direkt mit. Für einen Enduser ist Sqlite voll kommend ausreichend. Da die Datenmengen sehr klein sind, reicht die Datenbank sehr lange aus. Wer andere Datenbanken bereits laufen hat, kann durch Eingabe der URL/User/Pass ganz leicht verbinden.

Ich sehe es eher an eine zusätzliche Einnahmequelle für Bitwarden.

 

[Kachelkaiser]

Naja der Unterschied ist ja eben dass man nicht 11 sondern nur noch 1 Container benötigt. Außerdem ist man wohl nicht mehr auf MSSQL festgelegt.

Der Vorteil wäre meiner Meinung nach, dass es eben direkt von Bitwarden kommt und alle Funktionen unterstützt werden. Bei Vaultwarden fehlt das ein oder andere.

Vielleicht teste ich das die nächsten Tage mal.

 

[alexhell]

Sehe es wie @Kachelkaiser. Es ist dann kein Nachbau mehr. Die Features sind direkt dabei und man muss nicht mehr warten bis es portiert wurde. Ich weiß nicht wie es aktuell ist, aber als ich das mal getestet habe, ging auch der mobile Push Service nicht. Also, dass der Tresor automatisch synchronisiert wurde. Weil die API natürlich nicht von Bitwarden verwendet werden konnte. Man musste also immer manuell klicken, dass synchronisiert werden soll. Und das mit der Lizenz.... Das sind 10$ im Jahr. Das bezahle ich sehr gerne für den Dienst. Irgendwie muss das ja auch finanziert werden.

 

[EDvonSchleck]

Was fehlt dir denn in Vaultwarden?

An der Grafik kannst du genau erkennen, dass alles was "Unified deployment" als Voreil eingetragen ist, von Vaultwarden schon lange der Fall ist.



Auch sehe ich im Stack nicht das es 1 Container ist! Dazu ist es noch beta.

---
version: "3.8"

services:
  bitwarden:
    depends_on:
      - db
    env_file:
      - settings.env
    image: bitwarden/self-host:beta
    restart: always
    ports:
      - "80:8080"
    volumes:
      - bitwarden:/etc/bitwarden

  db:
    environment:
      MARIADB_USER: "bitwarden"
      MARIADB_PASSWORD: "super_strong_password"
      MARIADB_DATABASE: "bitwarden_vault"
      MARIADB_RANDOM_ROOT_PASSWORD: "true"
    image: mariadb:10
    restart: always
    volumes:
      - data:/var/lib/mysql

volumes:
  bitwarden:
  data:

Das Bitwarden vorher auf M$SQL gesetzt hat, ist wohl eher deren Schuld. Freie Alternativen gibt und gab es ja seit einer seeeehr langen Zeit.

Ich denke nicht das es ein „Renner“ wird. Für mich sieht es eher als ein „originaler“ Nachbau von Vaultwarden aus. Viele Environment sind dort seit einiger zeit enthalten. Jetzt möchte Bitwarden sich den Hype zu nutze machen und mit kassieren.

 

[alexhell]

Soweit ich weiß war das, weil Bitwarden war eine One Man Show war. Ein Entwickler hat das komplett alleine entwickelt und es in Azure gehostet. Und um sich das so einfach wie möglich zu machen hat er komplett alles von MS benutzt. Das Zusammenspiel war halt am einfachsten. Und daher war es MSSQL. Ich kann die Entscheidung da schon nachvollziehen. Und wenn ich Bitwarden selber hosten würde, dann würde ich das offizielle Image vorziehen. Das ist immer aktuell von den Funktionen.....

 

[Kachelkaiser]

Ich würde auch das Original der "Kopie" vorziehen. Was ist wenn Bitwarden eines Tages die API schließt oder verändert? Was passiert dann mit vaultwarden und die App Anbindung?

Wie gesagt ich schau mal die nächsten Tage ob ich etwas Zeit finde, es zu testen.

 

[EDvonSchleck]

Vaultwarden hat quasi die API nachgebaut. Was soll denn passieren, da Bitwarden Open Source ist. Ich denke eher das es ein Versuch ist $ zu machen und etwas Vergleichbares wie Vaultwarden anbieten. Für mich sieht es stark abgekupfert aus. Bis aus dem Push zu Mobil sehe ich aktuell kein Mehrwert. Bei Desktop wird dieses über Websocket realisiert. Außerdem synchronisiert die Anwendung bei jedem öffnen. Ob sich das Konzept durchsetzt, wird sich noch zeigen. Vaultwarden hat eine Menge Unterstützer. Ich bleibe bei Vaultwarden und beobachte es – selbst in dem Beitrag von Caschy sehe es einige genauso.

Und mit 1 Container war wohl nichts. Wenn das nicht lächerlich ist, damit zu werben.

 

[alexhell]

Klar würde vaultwarden die API wieder nachbauen. Die Frage ist nur wie lange das dauert. Und ein paar Dollar zu verdienen ist doch nicht schlimm. Irgendwie muss das doch finanziert werden. Oder arbeitest du immer umsonst für andere? Wie gesagt es kostet ganze 10$ im Jahr.
Und wegen abgekupfert. Weil sie ihr eigenes Produkt vereinfachen wollen? Guck dir doch erstmal an wie bitwarden entwickelt wurde. Es wurde von einem einzelnen entwickelt.... Es kann nicht alles direkt zu 100 Prozent super sein. Zum entwickeln sind die 11 Container auch praktischer als einer. Und ganz ehrlich wenn ich eine schlanke docker-compose habe, dann stören mich auch 11 Container nicht. Ich sehe da keinen großen Nachteil. Ob ich alles in einen Container packe oder in 11 ist kein Unterschied für die Benutzung. Wenn man Projekte mit Microservices umsetzt dann kommen noch mehr Container zusammen und da ist es auch kein Problem

Edit: ist doch nur ein Container. Die DB gehört ja nicht zu bitwarden. Sollen sie alle Datenbank in ihren Container packen? Du kannst ja eine vorhandene DB nutzen.

 

[EDvonSchleck]

Und Vaultwarden wurde auch erst von einem Programmierer angefangen. Ich denke, die Entscheidung von Bitwarden unterliegt die große Verbreitung und Erfolg von Vaultwarden, warum dieser Umbau überhaupt stattfindet.

Gegen eine Zahlung spricht ja nichts, Open Source sollte unterstützt werden, um das Projekt weiterzuführen. Ob sich Bitwarden aber mit diesem Abo durchsetzt, wird sich zeigen. Generell bin ich vorsichtig, gerade da Bitwarden eine erhebliche Summe von Investoren bekommen hat. Diese Gutmenschen machen ungern etwas umsonst.

 

[haydibe]

Vaultwarden implementiert die API von Bitwarden auf Basis von RUST. Es ist weder ein Fork, noch eine Kopie. Die Bitwarden-API ist öffentlich einsehbar.
Bitwarden wird niemals so effizient werden wie Vaultwarden, außer es wird plötzlich auch in RUST oder ähnlich effizientem wie C oder C++ geschrieben. Das "fette" Bitwarden basiert mwn. auf .NET (core?).

Ich halte das Argument mit API-Änderungen und neuen Features für irrelevant: die Leute mögen ihre Clients aktuell halten, aber wer das fette Bitwarden installiert hat, wird doch nicht sofort mit jedem Release aktualisieren. Die Spreizung der eingesetzten Versionen wird von bis gehen. Wenn es Breaking Changes gibt, dann werden die niemals von heute auf Morgen ausgerollt - das würde nämlich auch die zahlende Kundeschaft hart treffen. Bei sowas gibt es immer Vorlaufzeit - die wird auch Vaultwarden sicher nicht ungenutzt bleiben.

Ist doch schön, jetzt haben die, die wollen eine weitere Option. Ich bin schon gespannt auf Erfahrungsberichte nach etlichen Monaten der Nutzung.
Ich persönlich sehe zumindest bisher keinen Grund von Vaultwarden Wegzugwechseln.

 

[alexhell]

Vaultwarden unterstützt jetzt (seit gestern: https://github.com/dani-garcia/vaultwarden/releases) auch mobile Push. Das heißt bei jeder Änderung am Tresor wird die App automatisch synchronisiert. Ich habs mal direkt ausprobiert und ich musste bei Android erst die App Daten löschen und danach hat es funktioniert. Bei iOS ging es direkt.

 

[Kachelkaiser]

Hmm das funktioniert bei mir irgendwie nicht. Ich habe mir die beiden Keys geholt, die Umgebung des containers angepasst. Danach habe ich einen Ordner im Vault angelegt. In der App tut sich aber leider nix.

Cache der App habe ich auch gelöscht. im Protokoll steht leider auch kein Fehler drin. Ein manueller Sync des Tresors funktioniert aber.

Was mache ich falsch?

Edit: Neuinstallation der app hat geholfen. Ich hatte sie bisher aus F-Droid installiert. Das funktioniert leider nicht mehr. Mit der Version aus dem Playstore geht es jetzt aber.

 

[alexhell]

Ich habe nicht nur den Cache gelöscht. Ich habe alle Daten gelöscht. Ich musste dann die App auch neu einrichten.

 

[Kachelkaiser]

Dann hatte ich das falsch verstanden

Datenlöschen ist ja quasi ne Neuinstallation, also dann war es ähnlich wie bei mir.

 

[Ulfhednir]

Habe jetzt zwischenzeitlich auch die Änderungen übernommen. Wer noch einen Reverse Proxy im Einsatz hat, muss auch hier die Config anpassen.

 

[alexhell]

Ich habe einen Reverse Proxy im Einsatz und musste nichts anpassen. Was musstest du denn anpassen?

 

[Ulfhednir]

Na meine proxy-conf.

## Version 2023/05/31
# make sure that your vaultwarden container is named vaultwarden
# make sure that your dns has a cname set for vaultwarden
# set the environment variable WEBSOCKET_ENABLED=true on your vaultwarden container

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name vaultwarden.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 128M;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

    # enable for Authentik (requires authentik-location.conf in the location block)
    #include /config/nginx/authentik-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.21;
        set $upstream_port 7701;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ ^(/vaultwarden)?/admin {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.21;
        set $upstream_port 7701;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ (/vaultwarden)?/api {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.21;
        set $upstream_port 7701;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ (/vaultwarden)?/notifications/hub {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.21;
        set $upstream_port 7701;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ (/vaultwarden)?/notifications/hub/negotiate {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.21;
        set $upstream_port 7701;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

 

[alexhell]

So sieht meine auch aus. Aber bei mir sind die Sachen schon länger drin. Ich weiß allerdings nicht wann die dazu gekommen sind