Extras zur Blitz⚡Bank

Ein Sammelsurium von Tipps, Tricks und Sonstigem zum Phoenix Wallet und LNbits

1. Hilfe zum Prüfen der Dienste

1.1 Dienste manuell überprüfen

sudo systemctl status lnbits
sudo journalctl -u lnbits -f --since "2 hour ago"
sudo systemctl status phoenixd
sudo journalctl -u phoenixd -f --since "2 hour ago"
sudo systemctl status caddy
sudo journalctl -u caddy -f --since "2 hour ago"

1.2 Einfache Skriptabfrage erstellen

nano ~/check_services.sh

#!/bin/bash
if systemctl is-active --quiet phoenixd;  then
   echo  "Phoenixd is running."
else
   echo  "Phoenixd is not running."
fi
if systemctl is-active --quiet lnbits;  then
   echo  "LNbits is running."
else
   echo  "LNbits is not running."
fi
if systemctl is-active --quiet caddy;  then
   echo  "Caddy is running."
else
   echo  "Caddy is not running."
fi

STRG+X -> Y -> ENTER

chmod +x ~/check_services.sh
~/check_services.sh

-> Mit ~/check_services.sh könnt ihr das Skript jetzt immer abfragen.

2. Systempflege / Snapshot

2.1 Snapshot machen

sudo systemctl stop lnbits
sudo systemctl stop phoenixd
sudo shutdown -h now

-> Snapshot über die Webseite des Hosting Anbieters machen und danach den VPS wieder starten.

2.2 System Update

sudo systemctl stop lnbits
sudo systemctl stop phoenixd
sudo su -

Update durchführen:

sudo apt update && sudo apt upgrade -y

-> Ggf. bestätigen mit y und Enter

Sicherheitsupdates von Ubuntu installiert der Server dank unattended-upgrades (siehe Hauptanleitung) bereits selbst. Dieser manuelle Lauf holt zusätzlich alle übrigen Updates, auch für Caddy. Ob ein Neustart nötig ist, zeigt cat /var/run/reboot-required. Erscheint „No such file“, könnt ihr euch den Neustart sparen.

reboot

-> Kurz warten und dann neu einloggen

2.3 LNbits update

sudo systemctl stop lnbits
cd ~/lnbits
git pull --rebase
uv sync --all-extras

Hinweis: Dieser Weg gilt für LNbits, das wie in der Hauptanleitung mit uv installiert wurde. Habt ihr LNbits noch mit der älteren Poetry-Anleitung eingerichtet, installiert zuerst uv (siehe Hauptanleitung, Kapitel 5), ändert in /etc/systemd/system/lnbits.service die Zeile ExecStart auf /home/blitzbank/.local/bin/uv run lnbits --port 5000 und führt danach sudo systemctl daemon-reload aus.

Version prüfen:

git describe --tags
# Alle Infos abfragen
git remote -v && echo "---" && git status -sb && echo "---" && git log -1 --oneline

LNbits neu starten:

sudo systemctl start lnbits

-> Die Version könnt ihr auf der LNbits Startseite unten links prüfen

LNbits Protokoll überprüfen:

sudo journalctl -u lnbits -f --since "2 hour ago"

-> SUCCESS | ✔️ Backend PhoenixdWallet connected and with a balance of xxx msat.

-> Empfehlung: Jetzt noch mit einem Browser Inkognito Fenster und dem LNbits Admin Account einloggen und die Extensions updaten.

2.4 Phoenix Wallet Update

Verwendete Phoenixd Version prüfen:

~/phoenixd/phoenix-cli getinfo

Vergleicht sie mit der neuesten Version: https://github.com/ACINQ/phoenixd/releases

Dienste stoppen:

sudo systemctl stop lnbits
sudo systemctl stop phoenixd

Version aktualisieren. Nachfolgend die Versionsnummern in den Zeilen 2 bis 4 anpassen.

cd ~/phoenixd
wget https://github.com/ACINQ/phoenixd/releases/download/v0.9.3/phoenixd-0.9.3-linux-x64.zip
unzip -o -j phoenixd-0.9.3-linux-x64.zip
rm phoenixd-0.9.3-linux-x64.zip
./phoenixd --version

-> unzip -o überschreibt die alten Dateien ohne Rückfrage. Am Ende wird die neue Version angezeigt.

Phoenix und LNbits starten:

sudo systemctl restart phoenixd
sleep 5
~/phoenixd/phoenix-cli getinfo | grep version
ls -l ~/.phoenix
sudo systemctl restart lnbits

Phoenixd Version prüfen:

~/phoenixd/phoenix-cli getinfo

-> Siehe unten „version“

In den LNbits Protokollen prüfen, ob das PhoenixdWallet erfolgreich eingebunden wurde:

sudo journalctl -u lnbits -f --since "2 hour ago"

-> SUCCESS | ✔️ Backend PhoenixdWallet connected and with a balance of xxx msat.

3. Nützliches zu LNbits

3.1 LNbits Erweiterungen aktivieren

Im Super User Account links unter Extensions / ALL alle Erweiterungen, die ihr aktivieren möchtet, mit MANAGE anwählen, das neueste Repository auswählen und installieren. Unter INSTALLED findet ihr die aktivierte Erweiterung.

3.2 Wallets füllen über TOPUP

Wenn ihr komplett neue Wallets anlegt, ist das auch immer ein neuer User Account. Damit ihr diesen Benutzer in eurer Datenbank auch findet, gebt dem Account einen Username. Dann könnt ihr im Super User Account unter Users / TOPUP eine spezielle Wallet auffüllen, ohne eine Lightning-Transaktion. Sucht dazu nach dem Username in der Liste, klickt links auf die drei Balken mit Show Wallets und dann auf Copy Wallet ID. Nach dem Top-Up einen Webseiten-Refresh durchführen. Da LNbits die Wallet-Balancen in einer Datenbank verwaltet, könnt ihr hier eintragen, was ihr wollt. Die „echten“ Satoshis stecken im Lightning-Channel der Finanzierungsquelle.

3.3 Datenbank Backup / Recovery

Das Sichern einer LNbits SQLite Datenbank (Standard) ist recht einfach. Man sollte nur einmal den LNbits Server herunterfahren und dann den Ordner ~/lnbits/data sichern. Dazu wird er hier mit dem Befehl tar komprimiert und die Datei danach auf dem Client PC gezogen.

Backup machen und extern sichern

Auf dem Server (VPS):

sudo systemctl stop lnbits
cd ~/lnbits
tar cfv data_backup_jjmmdd.tar ./data
sudo systemctl start lnbits

Auf dem Client (Rechner):

scp blitzbank@yourIPaddress:/home/blitzbank/lnbits/data_backup_jjmmdd.tar ./

-> Jetzt solltet ihr die Datei data_backup_jjmmdd.tar auf eurem Rechner gesichert haben und LNbits wieder laufen.

Sicherung wiederherstellen

Um die Datenbank wieder herzustellen, geht ihr den umgekehrten Weg:

Auf dem Client (Rechner):

scp data_backup_jjmmdd.tar blitzbank@yourIPaddress:/home/blitzbank/lnbits/

Auf dem Server (VPS):

sudo systemctl stop lnbits
cd ~/lnbits
mv data data.backup
tar -xvf data_backup_jjmmdd.tar
sudo systemctl start lnbits

-> Damit sollte das Backup wieder hergestellt worden sein.
-> Der Befehl mv benennt den Ordner „data“ nur um zu „data.backup“. Damit könnt ihr notfalls wieder zurück.

Hinweis: Habt ihr einen individuellen Port für die SSH-Verbindung festgelegt, müsst ihr folgende Befehle für die Übertragung verwenden:

scp -P 1001 blitzbank@yourIPaddress:/home/blitzbank/lnbits/data_backup_jjmmdd.tar ./
scp -P 1001 data_backup_jjmmdd.tar blitzbank@yourIPaddress:/home/blitzbank/lnbits/

-> Wichtig ist hier, das große „P“ zu verwenden und nicht wie sonst das kleine „p“.

3.4 Cronjob Backups und externe Sicherung

Auf dem Zielrechner

Richtet auf einem zweiten VPS, den ihr als Backup-Speicher verwenden möchtet, einen Benutzer namens „backup“ ein. Dieser Benutzer benötigt keine Adminrechte, aber einen Eintrag in der sshd_config.

sudo adduser backup

-> Passwort vergeben, die Dateneingabe ist optional.

Den Benutzer nicht zu „sudo“ hinzufügen, er braucht keine Adminrechte. Nur die Konfigurationsdatei des OpenSSH Servers bearbeiten:

sudo nano /etc/ssh/sshd_config

-> Fügt die Zeile hinzu. Steht dort bereits eine AllowUsers-Zeile für euren Admin-Benutzer, lasst sie stehen.

AllowUsers backup

Den ssh-Dienst einmal mit $ sudo systemctl restart ssh neu starten und dann mit dem neuen User anmelden, wenn ihr noch kein SSH-Schlüsselpaare verwendet. Ansonsten lieber den User wie hier erstmal direkt anmelden:

su backup

Ein Ordner „backups“ anlegen und den file „authorized_keys“ öffnen:

mkdir ~/backups
mkdir ~/.ssh
nano ~/.ssh/authorized_keys 

-> Hier den .pub-Key des Blitz⚡Bank VPS einfügen.

Auf der Quelle des Backups

Auf dem Blitz⚡Bank VPS anmelden, ein Verzeichnis mit dem Namen „backups“ anlegen und ein eigenes Schlüsselpaar für die Backups erzeugen (ohne Passphrase, damit der Cronjob ohne Eingabe funktioniert):

mkdir ~/backups
ssh-keygen -t ed25519
cat ~/.ssh/id_ed25519.pub

-> Die Ausgabe von cat ist der .pub-Key, den ihr beim Benutzer „backup“ auf dem Zielrechner in die Datei authorized_keys einfügt (siehe oben).

Testet den Archivierungsbefehl:

tar cfv ~/backups/data.tar ~/lnbits/data

-> Jetzt müsste in dem Verzeichnis „backups“ eine „data.tar“ Datei zu finden sein.

Testen des Transferbefehls:

scp -P 1001 -i ~/.ssh/id_ed25519 ~/backups/data.tar backup@backupIPaddress:~/backups/data_$(date +\%Y\%m\%d_\%H\%M).tar

Hinweis: Der Transfer bezieht sich hier auf einen Backup-VPS, der einen SSH-Schlüssel (id_ed25519) und einen individuellen SSH-Port (1001) verwendet. Siehe dazu: „Erweitertes Härten des VPS-Zugangs“ weiter unten.

-> Überprüft den Empfang auf dem Ziel.

Einen Cronjob einrichten, um die zeitgesteuerte Archivierung und Übertragung zum Zielrechner durchzuführen:

crontab -e

Füllen mit:

# Backup every hour at minute 0
0 */1 * * * tar cfv ~/backups/data_$(date +\%H\%M).tar ~/lnbits/data
# Daily backup at 5 minutes after 0 o'clock
5 0 * * * tar cfv ~/backups/data_$(date +\%Y\%m\%d).tar ~/lnbits/data
# Daily backup at 10 minutes after 0 o'clock for transfer
10 0 * * * tar cfv ~/backups/data.tar ~/lnbits/data
# Daily transfer at 15 minutes after 0 o'clock 
15 0 * * * scp -P 1001 -i ~/.ssh/id_ed25519 ~/backups/data.tar backup@backupIPaddress:~/backups/data_$(date +\%Y\%m\%d_\%H\%M).tar
# Delete all entries older than 7 days at 20 minutes after 0 o'clock
20 0 * * * find ~/backups/* -type f -mtime +7 -delete

-> Vergesst nicht, die Backups auf der Empfängerseite ebenfalls regelmäßig mit einem Cronjob zu löschen.

Hinweis zur Konsistenz: Ein tar auf die laufende SQLite-Datenbank kann eine unbrauchbare Kopie liefern, wenn LNbits genau in diesem Moment schreibt. Sicherer ist sqlite3 .backup. Installiert es mit sudo apt install sqlite3 -y und ersetzt die beiden täglichen tar-Zeilen (00:05 und 00:10) durch diese eine Zeile. Der Transfer um 00:15 muss dann die Datei database.sqlite3 statt data.tar übertragen:

5 0 * * * sqlite3 ~/lnbits/data/database.sqlite3 ".backup '/home/blitzbank/backups/database.sqlite3'"

Den verfügbaren Speicherplatz könnt ihr mit dem Befehl df -T -h prüfen. Mit dem Befehl ls -lha könnt ihr Dateien in einer menschenlesbaren Form darstellen.

4. Nützliches zu Phoenix

4.1 Phoenix Hilfe

~/phoenixd/phoenix-cli -h

   getinfo                Show basic info about your node
   getbalance             Returns your current balance
   estimateliquidityfees  Estimates the liquidity fees for a given amount, at current feerates.
   listchannels           List all channels
   getoutgoingpayment     Get outgoing payment
   listoutgoingpayments   List outgoing payments
   getincomingpayment     Get incoming payment
   listincomingpayments   List incoming payments
   createinvoice          Create a Lightning invoice
   getoffer               Return a Lightning offer (static invoice)
   getlnaddress           Return a BIP-353 Lightning address (there must be a channel)
   payinvoice             Pay a Lightning invoice
   payoffer               Pay a Lightning offer
   paylnaddress           Pay a Lightning address (BIP353 or LNURL)
   decodeinvoice          Decode a Lightning invoice
   decodeoffer            Decode a Lightning offer
   lnurlpay               Pay a LNURL
   lnurlwithdraw          Withdraw funds from a LNURL service
 

4.2 Phoenix Wallet leeren

Wollt ihr das Phoenix Wallet komplett leeren, müsst ihr zuvor den Lightning-Kanal schließen. Das geht über die Befehlszeile mit folgendem Befehl:

~/phoenixd/phoenix-cli closechannel --channelId=4bc2cc34.. --address=bc1qw5h27.. --feerateSatByte=4

Wie ihr seht, benötigt ihr noch drei Dinge: die channelId, die address, zu der eure verbleibende Outbound-Liquidität transferiert werden soll, und die feerateSatByte.

Die channelId findet ihr hier:

~/phoenixd/phoenix-cli getinfo

Die Bitcoin-Adresse, zu der die verbleibenden Funds gesendet werden sollen, lasst ihr euch am besten von eurer BitBox02 geben. Ihr könnt aber auch das BlueWallet, Phoenix oder ein anderes Bitcoin-Wallet verwenden. Der Adresstyp ist egal. Das neue Taproot-Format p2tr funktioniert auch.

Die feerateSatByte ermittelt ihr am besten mit mempool.space. Schaut einfach, was in letzter Zeit so übliche Werte waren. Wer sich nicht sicher ist, kann mal bei whatthefee.io. nachsehen. Ich würde jedoch niemals unter 3 sat/vB gehen.

Als Bestätigung bekommt ihr nur eine Zeile mit der closingTxId (z. B. 126aea45be230..) angezeigt. Den Status der Tx könnt ihr dann auch wieder mit der Id im mempool.space überprüfen.

4.3 Nützliche Phoenix Befehle

~/phoenixd/phoenix-cli getinfo
~/phoenixd/phoenix-cli createinvoice \
    --description "my first invoice" \
    --amountSat 200000
~/phoenixd/phoenix-cli listchannels | grep "txId"
~/phoenixd/phoenix-cli getlnaddress
~/phoenixd/phoenix-cli createinvoice --amountSat=1234 --desc="comment"
~/phoenixd/phoenix-cli payinvoice --invoice lnbc3320..
~/phoenixd/phoenix-cli paylnaddress --amountSat=2100 --address="axelhamburch@ereignishorizont.xyz" --message="Danke für die Blitz⚡Bank"
~/phoenixd/phoenix-cli decodeinvoice --invoice=lnbc2210n..

5. Nützliches zu Caddy

5.1 Caddy Version prüfen und updaten

Caddy ist der Webserver, der eure Domains mit HTTPS versorgt und die Anfragen an LNbits weiterleitet. Auch er sollte ab und zu aktualisiert werden. Zuerst die installierte Version prüfen:

caddy version

-> Die Ausgabe sieht z. B. so aus: v2.10.2 h1:g/gTYjGMD0dec+.... Wichtig ist nur der erste Teil (v2.10.2). Vergleicht ihn mit der neuesten Version auf https://github.com/caddyserver/caddy/releases. Caddy wird bei der Blitz⚡Bank aus der offiziellen Paketquelle installiert, daher reicht in der Regel ein normales Update:

sudo apt update
sudo apt install --only-upgrade caddy
caddy version

-> Steht hinterher immer noch eine ältere Version als auf GitHub da, prüft mit apt policy caddy, ob die Paketquelle dl.cloudsmith.io/public/caddy/stable überhaupt dort auftaucht. Fehlt sie, holt euch aktuelle Einrichtungsbefehle von caddyserver.com/docs/install.

Hinweis zu abgelaufenen Signaturen: Meldet apt update einen Fehler wie EXPKEYSIG ... Caddy Web Server, ist nur der GPG-Schlüssel der Paketquelle abgelaufen. Mit folgendem Befehl holt ihr ihn neu (die bestehende Schlüsseldatei wird dabei mit --yes ohne Rückfrage überschrieben):

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --yes --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo apt update

Mit sudo apt upgrade aus Kapitel 2.2 wird Caddy mit aktualisiert. Die automatischen Sicherheitsupdates (unattended-upgrades) aus der Hauptanleitung erfassen die Caddy-Paketquelle nicht, ihr müsst also gelegentlich selbst updaten. Nach dem Update lohnt ein kurzer Blick, ob der Dienst noch läuft:

systemctl is-active caddy

-> active muss erscheinen und eure Webseiten müssen weiterhin erreichbar sein.

5.2 Zugriffsprotokoll (Access-Log) einschalten

Caddy schreibt in der Standardeinstellung kein Zugriffsprotokoll. Es gibt also keine Aufzeichnung darüber, wer wann welche Seite aufgerufen hat. Im Alltag fällt das nicht auf. Nach einem Einbruch fehlt damit aber die wichtigste Spur: die IP-Adresse und der genaue Ablauf des Angriffs.

Mit dieser Anleitung schreibt Caddy für alle eure Domains ein gemeinsames Zugriffsprotokoll nach /var/log/caddy/access.log. Dabei

• werden API-Schlüssel aus der URL ausgeblendet (LNbits übergibt z. B. ?api-key=… oder ?usr=… in der Adresse),
• lässt Caddy Cookies und Passwort-Header schon von sich aus weg,
• wird das Protokoll nach 30 Tagen gelöscht und auf 10 Dateien zu je 50 MB begrenzt.

Warum das wichtig ist: Im Oktober 2026 wurde über eine Sicherheitslücke im Bolt Card Hub ein Lightning-Knoten leergeräumt (GHSA-vmxv-qh54-c79j). Was passiert war, ließ sich über die Protokolle von phoenixd und dem Hub genau rekonstruieren. Nur eine Frage blieb offen: Von welcher IP-Adresse kam der Angreifer? Der Hub protokolliert keine IP-Adressen und Caddy hatte kein Zugriffsprotokoll. Für eine Anzeige bei der Polizei wäre genau diese Angabe wertvoll gewesen.

Voraussetzungen: Caddy ist als Systemdienst installiert (Ubuntu/Debian-Paket), die Konfiguration liegt in /etc/caddy/Caddyfile und der Ordner /var/log/caddy existiert und gehört dem Benutzer caddy (beim Paket der Fall).

Schritt 1: Sicherung anlegen

sudo cp /etc/caddy/Caddyfile /etc/caddy/Caddyfile.bak-$(date +%F)

Schritt 2: Baustein (Snippet) definieren

Ein Snippet ist ein Konfigurationsbaustein, den man einmal oben im Caddyfile definiert und dann in jede Seite einbindet. So steht die Log-Einstellung nur an einer Stelle. Der Baustein wird hier in eine neue Datei /tmp/Caddyfile.neu vor den bisherigen Caddyfile gesetzt. Die laufende Konfiguration bleibt dabei unberührt.

sudo tee /tmp/zugriffslog.caddy > /dev/null << 'EOF'
(zugriffslog) {
    log {
        output file /var/log/caddy/access.log {
            roll_size 50MiB
            roll_keep 10
            roll_keep_for 720h
        }
        format filter {
            fields {
                request>uri query {
                    replace api-key REDACTED
                    replace usr REDACTED
                    replace wal REDACTED
                }
            }
        }
    }
}

EOF
sudo sh -c 'cat /tmp/zugriffslog.caddy /etc/caddy/Caddyfile > /tmp/Caddyfile.neu'

• roll_size 50MiB: ab 50 MB wird eine neue Datei angefangen
• roll_keep 10: höchstens 10 alte Dateien werden aufbewahrt
• roll_keep_for 720h: alte Dateien werden nach 30 Tagen gelöscht
• replace api-key REDACTED: der Wert von ?api-key= erscheint im Protokoll als REDACTED

-> Weitere geheime URL-Parameter könnt ihr nach demselben Muster ergänzen.

Schritt 3: Baustein in jede Seite einbinden

Unter jeder Zeile der Form domain.de { muss import zugriffslog stehen. Das erledigt dieser Befehl automatisch (Kommentarzeilen bleiben unberührt):

sudo sed -E -i '/^[A-Za-z0-9*][A-Za-z0-9.*:,-]*( [A-Za-z0-9.*:,-]+)* \{$/a\    import zugriffslog' /tmp/Caddyfile.neu
diff /etc/caddy/Caddyfile /tmp/Caddyfile.neu

-> Kontrolliert die Ausgabe von diff: Oben muss der Baustein stehen und unter jeder Domain eine Zeile > import zugriffslog. Fehlt eine Domain (z. B. weil sie eingerückt ist), fügt die Zeile dort von Hand ein:

sudo nano /tmp/Caddyfile.neu

Ein fertiger Seitenblock sieht dann so aus:

lnbits.example.org {
    import zugriffslog
    reverse_proxy 127.0.0.1:5000
}

Schritt 4: Prüfen und aktivieren

Erst prüfen, dann übernehmen. Solange validate einen Fehler meldet, bleibt die laufende Konfiguration unverändert. Die Prüfung läuft als Benutzer caddy, damit eine dabei angelegte Protokolldatei nicht root gehört (sonst könnte Caddy später nicht hineinschreiben).

sudo -u caddy caddy validate --config /tmp/Caddyfile.neu --adapter caddyfile
sudo cp /tmp/Caddyfile.neu /etc/caddy/Caddyfile
sudo systemctl reload caddy
systemctl is-active caddy

-> Am Ende muss active erscheinen.

Schritt 5: Testen

Ruft eine eurer Seiten im Browser auf und schaut ins Protokoll:

sudo tail -n 3 /var/log/caddy/access.log

-> Es erscheint eine Zeile pro Aufruf im JSON-Format.

Protokoll lesen

Mit jq werden die Einträge lesbar. Installation:

sudo apt install jq

Laufend mitlesen (Zeit, IP, Domain, Methode, Pfad, Status):

sudo tail -f /var/log/caddy/access.log | jq -c '{ts: (.ts|todate), ip: .request.remote_ip, host: .request.host, m: .request.method, uri: .request.uri, status}'

Alle Aufrufe von Admin-Bereichen:

sudo jq -c 'select(.request.uri|startswith("/admin")) | {ts: (.ts|todate), ip: .request.remote_ip, host: .request.host, uri: .request.uri, status}' /var/log/caddy/access.log

Welche IPs haben am häufigsten zugegriffen?

sudo jq -r '.request.remote_ip' /var/log/caddy/access.log | sort | uniq -c | sort -rn | head

-> Die Zeitangaben (ts) sind in UTC. Für deutsche Zeit eine Stunde (Winterzeit) bzw. zwei Stunden (Sommerzeit) addieren.

Datenschutz

Das Protokoll enthält die IP-Adressen eurer Besucher. Das sind personenbezogene Daten. Die Aufbewahrung ist deshalb auf 30 Tage begrenzt und das Protokoll ist nur mit sudo lesbar. Betreibt ihr Dienste für andere (z. B. LNbits-Konten), solltet ihr in eurer Datenschutzerklärung erwähnen, dass Zugriffe zur Sicherheit 30 Tage lang protokolliert werden.

Rückgängig machen

sudo cp /etc/caddy/Caddyfile.bak-JJJJ-MM-TT /etc/caddy/Caddyfile
sudo systemctl reload caddy

-> JJJJ-MM-TT durch das Datum der Sicherung aus Schritt 1 ersetzen (ls /etc/caddy/ zeigt sie an).

6. Erweitertes härten des VPS Zugangs

Hinweis: Schlüssel-Login, deaktivierter Passwort-Login und gesperrter root-Login sind bereits in der Hauptanleitung eingerichtet (Kapitel 3). Hier findet ihr die Hintergründe und zusätzlich die Änderung des SSH-Ports. Die nachfolgenden Methoden zur weiteren Stärkung der Sicherheit sind relevant und gut. Aber allzu oft passieren dabei Fehler und man sperrt sich selber aus. Macht als erstes einen Snapshot eures VPS, damit ihr immer wieder zurück könnt. Dann geht alles sehr langsam Schritt für Schritt durch und testet immer den neuen Zugang, bevor ihr etwas deaktiviert! Zum Beispiel den Passwort Zugang, den root-User oder einen Port.

Wichtig bei Ubuntu 24.04: Einstellungen in Dateien unter /etc/ssh/sshd_config.d/ haben Vorrang vor der Hauptdatei /etc/ssh/sshd_config. Manche Hoster schalten dort den Passwort-Login wieder ein (z. B. in 50-cloud-init.conf). Ob eure Einstellungen tatsächlich gelten, prüft ihr nach jedem Neustart des SSH-Dienstes mit diesem Befehl:

sudo sshd -T | grep -Ei '^(passwordauthentication|permitrootlogin|port|allowusers) '

-> Erwartet werden passwordauthentication no und permitrootlogin no. Steht dort etwas anderes, legt die Einstellungen wie in der Hauptanleitung in der Datei /etc/ssh/sshd_config.d/00-hardening.conf an.

6.1 SSH Key verwenden

Die Verwendung von SSH-Schlüsselpaare klingt erstmal kompliziert und ist etwas verwirrend, aber wenn man es erstmal verstanden hat, ist es recht einfach. Ich lasse es mal ChatGPT erklären:

Ein SSH-Schlüsselpaar ist eine Art von Sicherheitswerkzeug, das zur sicheren Anmeldung auf einem Computer oder Server verwendet wird. Stell es dir als ein Schloss und einen passenden Schlüssel vor, die zusammen funktionieren, um eine Tür zu öffnen – nur hier geht es um digitale Sicherheit.

Hier sind die beiden Teile des SSH-Schlüsselpaares:

1. Privater Schlüssel (Private Key): Dieser ist wie dein persönlicher, geheimer Schlüssel. Du solltest ihn niemals mit jemandem teilen. Er bleibt immer sicher auf deinem eigenen Computer.

2. Öffentlicher Schlüssel (Public Key): Dieser ist wie das Schloss, das du auf den Server montierst. Er kann von anderen Leuten gesehen werden, weil es nichts ausmacht, wenn er öffentlich bekannt ist. Der öffentliche Schlüssel wird auf den Server kopiert, auf den du dich einloggen willst.

Wie funktioniert das?

1. Wenn du dich auf einem Server anmelden möchtest, prüft der Server deinen öffentlichen Schlüssel.
2. Dein Computer (mit dem privaten Schlüssel) "spricht" mit dem Server, und der Server prüft, ob der private Schlüssel zum öffentlichen passt.
3. Passt er, darfst du rein, ganz ohne Passwort. Der private Schlüssel verlässt dabei nie deinen Computer.

Ein Schlüsselpaar könnt ihr ganz einfach auf eurem Rechner selbst generieren. Öffnet dazu euer Terminal, als würdet ihr euch einloggen, und generiert dann mit folgendem Befehl ein Schlüsselpaar:

ssh-keygen

Als erstes werdet ihr gefragt, wo ihr das Schlüsselpaar ablegen möchtet. Wenn ihr einfach ENTER drückt, wird der in Klammern vorgeschlagene Pfad und Dateiname übernommen. Anschließend erscheint die Aufforderung „Enter passphrase“. Hier könnt ihr den Schlüssel zusätzlich verschlüsseln. Diese Passphrase ist das Passwort zum Entschlüsseln des privaten Schlüssels. Meldet ihr euch beim Remote-Server an, muss der private Schlüssel mit der Passphrase entschlüsselt werden. Ihr benötigt dann jedoch nicht mehr das Passwort für den Benutzer, um euch anzumelden. Die Passphrase ist nicht zwingend erforderlich, bietet jedoch zusätzliche Sicherheit. Achtet darauf, die Schlüsseldatei und die Passphrase nicht zu verlieren. Nachfolgend findet ihr ein Bild zur Generierung eines SSH-Schlüsselpaares auf einem Windows 11 Rechner.

Bild: Generierung eines SSH-Schlüsselpaares

Ed25519 ist ein moderner asymmetrischer Verschlüsselungsalgorithmus. Der private Schlüssel id_ed25519 und der öffentliche Schlüssel id_ed25519.pub wurden auf dem Rechner in dem Pfad C:\Users\<Benutzername>\.ssh abgelegt. Es sind zwei Dateien, die ihr mit einem einfache Textreader wie Notepad öffnen und lesen könnt. Alternativ könnt ihr den Befehl cat id_ed25519.pub verwenden, dann wird euch im Terminal der Schlüssel angezeigt. Die Datei known_hosts ist eine Datei die euer Rechner anlegt um private Schlüssel von anderen Rechnern zu speichern. Sie dient nur um die Authentizität des anderen Rechners zu verifizieren.

Kurzer Einschub zur Info: Installiert ihr euren Server also mal neu, hat er ein neues Schlüsselpaar generiert und ihr bekommt folgende Warnmeldung.

Bild: Warnmeldung „man-in-the-middle attack“

In diesem Fall könnt ihr beruhigt sein, da ihr jetzt ja wisst, wieso die Meldung kommt, der Schlüssel hat sich mit dem neu Aufsetzen geändert. Um die zu beheben müsst ihr nur den Schlüssel aus der known_hosts Datei löschen, dann legt der Rechner beim nächsten Login den neuen Schlüssel vom Server wieder in der Datei ab. Er zeigt euch mit der Meldung auch an wo die Datei liegt. In diesem Fall im Ordnerpfad: C:\Users\<Benutzername>\.ssh.

Weiter geht.. Jetzt könnt ihr den Inhalt des öffentlichen Schlüssels id_ed25519.pub lesen, markieren und in die Zwischenablage kopieren. Dann den Schlüssel in der Befehlszeile eures Blitz⚡Bank-Server in die Datei authorized_keys einfügen:

mkdir ~/.ssh
nano ~/.ssh/authorized_keys 

-> STRG+X -> Y -> ENTER.

Jetzt könnt ihr den Schlüssel testen, indem ihr euch einmal mit dem Befehl exit ausloggt und dann neu anmeldet. Entweder werdet ihr wie von Zauberhand eingeloggt, oder wenn ihr einen Passwortschutz für den Schlüssel vergeben habt, werdet ihr nach dem Passwort zum Entschlüsseln gefragt und dann eingeloggt.

Wichtig: Hinterlegt euren Schlüssel beim blitzbank-User. Den root-Login schaltet ihr später ohnehin ab (6.3). Solltet ihr den root-Zugang weiter nutzen wollen, muss der Schlüssel auch dort in /root/.ssh/authorized_keys stehen.

Hinweis: Wenn ihr bei der Login-Abfrage mit eurem verschlüsselten Schlüssel einfach ENTER drückt, erscheint als zweite Option die Passwortabfrage. Probiert es aus!

6.2 Passwort Login deaktivieren

Wenn ihr sicher Zugang mit eurem SSH-Schlüssel habt, könnt ihr den Login per Passwort deaktivieren. Bevor ihr dass tut, richtet am besten einen zweiten Rechner ein, mit dem ihr Notfalls Zugang bekommt. Alternativ könnt ihr den Private Key id_ed25519 auch selbst sichern. Der öffentliche Schlüssel ist nicht kritisch, der private Schlüssel hingegen schon.

Um den Login per Passwort zu deaktivieren:

sudo nano /etc/ssh/sshd_config

PasswordAuthentication auf no setzen (bei Ubuntu 24.04 besser in der Datei /etc/ssh/sshd_config.d/00-hardening.conf, siehe Hinweis oben):

PasswordAuthentication no

-> STRG+X -> Y -> ENTER

Den SSH-Server einmal neu starten:

sudo systemctl restart ssh

-> Loggt euch jetzt neu ein und drückt die SSH-Key Abfrage mit ENTER weg, dann solltet ihr keine Passwortabfrage mehr sehen. Das gilt jetzt für alle Benutzer.

6.3 Login per root-User deaktivieren

Da der root-User ein bekanntes Angriffsziel ist, kann man den Login dafür deaktivieren.

sudo nano /etc/ssh/sshd_config

PermitRootLogin no
# AllowUsers root

-> Eines von beiden reicht schon aus.

-> STRG+X -> Y -> ENTER

Startet jetzt den SSH-Server einmal neu:

sudo systemctl restart ssh

-> Versucht euch mit dem root-User anzumelden -> Das sollte jetzt nicht mehr gehen, nur noch der blitzbank-User sollte mit SSH-Key funktionieren.

6.4 Portzugang individualisieren (SSH Port 22 -> 1001)

Die Port Nummer (1001) für die Firewall könnt ihr frei wählen:

sudo ufw allow 1001 comment 'OpenSSH neu'
sudo nano /etc/ssh/sshd_config

Fügt eine weitere Zeile mit dem zusätzlichen Port ein:

Port 1001 

-> STRG+X -> Y -> ENTER

sudo systemctl restart ssh

Einmal mit exit ausloggen und neu einloggen, mit einem etwas abgewandelten Befehl:

ssh -p 1001 blitzbank@yourIPaddress

-> Achte auf das -p 1001. Die Portfreigabe für 1001 gilt jetzt für alle User.

Hinweis Ubuntu 24.04: Der SSH-Dienst wird dort über ssh.socket gestartet. Klappt der Login auf Port 1001 nicht, obwohl die Konfiguration stimmt (nicht ausloggen, sondern in der noch offenen Verbindung prüfen), lest die Konfiguration neu ein und prüft die lauschenden Ports:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -tln | grep -E ':22|:1001'

Jetzt die Freigabe für den Standard Port 22 in der Firewall (ufw) wieder entfernen und den Status betrachten. Eine zusätzliche deny-Regel würde nichts bewirken, denn ufw wertet die Regeln der Reihe nach aus und die ältere allow-Regel für Port 22 greift zuerst:

sudo ufw delete allow 22
sudo ufw status

Jetzt den Port Zugang in der SSH-Config deaktivieren:

sudo nano /etc/ssh/sshd_config

Die Zeile Port 22 mit # auskommentieren:

 # Port 22 

STRG+X -> Y -> ENTER

Systemdienst einmal neu starten:

sudo systemctl restart ssh

Loggt euch mit exit aus und dann wieder ein, um den Zugang zu überprüfen – in der Hoffnung, dass ihr euch nicht selbst ausgesperrt habt. 😉

Wichtig für fail2ban: Der Schutz vor Brute-Force-Angriffen aus der Hauptanleitung überwacht standardmäßig nur Port 22. Weist ihn auf den neuen Port hin:

sudo nano /etc/fail2ban/jail.local

[sshd]
enabled = true
port = 1001

-> STRG+X -> Y -> ENTER, danach sudo systemctl restart fail2ban und mit sudo fail2ban-client status sshd prüfen.

Damit habt ihr dem Server eine große Portion mehr Sicherheit hinzugefügt. 💪 Ihr habt nur ein kleines verstecktes Türchen offen gelassen. Bewahrt den Zugang und das Wissen darüber gut auf.

7. Sonstiges

7.1 Lightning Adresse und Nostr NIP-05 ID

Durch LNbits haben wir mit der Erweiterung „Pay Links“ die Möglichkeit, eine Lightning Adresse zu erzeugen. Frei nach dem Format username@yourdomain.com. Die Lightning Adresse könnt ihr z.B. in eurem Nostr Account hinterlegen und schon könnt ihr Lightning⚡Zaps über Nostr empfangen. Dem Sender wird dies als Zap-Symbol und als Erhöhung des Gesamtbetrags zu eurer Note angezeigt. Zusätzlich kann man beim Anlegen einer neuen Pay Link Instanz auch optional „Enable nostr zaps“ aktivieren. Damit wird der Zap auch eurem Client zurückgemeldet. Ihr bekommt also aktiv eine Nachricht und könnt es in der Zap-History verfolgen.

Nostr Profile haben zusätzlich noch die Option, eine NIP-05 ID zu hinterlegen. Damit könnt ihr nachweisen, dass euch die Domain gehört, bzw. dass der Username auf dieser Domain einzigartig euer ist. Die NIP-05 ID sieht genauso aus wie eure Lightning Adresse username@yourdomain.com. Der Server yourdomain.com muss bei einer Anfrage nach dem Benutzer username nur gegenprüfen, ob der Nutzer, der verifiziert werden soll, auch den gleichen npub (öffentlicher Nostr Schlüssel) hat wie der, der am Server hinterlegt wurde. Passt das zusammen, bekommt das Profil im Nostr Client ein verified ✅ Haken.

Mit der Blitz⚡Bank habt ihr bereits alles, was ihr dafür braucht. Ihr müsst nur den Caddy Eintrag für die Domain yourdomain.com etwas erweitern. Aber zuvor müsst ihr noch den npub in ein Hex-Format übertragen. Das kann man sehr einfach mit einem Key Converter machen. Bitte achtet darauf, nur den npub zu verwenden, nicht den nsec!

Dann den Caddyfile mit dem Befehl sudo nano /etc/caddy/Caddyfile aufrufen und den NIP-05 Teil hinzufügen:

yourdomain.com {
  handle /api/v1/payments/sse* {
    reverse_proxy 127.0.0.1:5000 {
      header_up X-Forwarded-Host yourdomain.com
      transport http {
         keepalive off
         compression off
      }
    }
  }
  reverse_proxy 127.0.0.1:5000 {
    header_up X-Forwarded-Host yourdomain.com
  }
  # Nostr NIP-05 direkt Antwort
   handle /.well-known/nostr.json {
   header Content-Type application/json
   header Access-Control-Allow-Origin *
   respond `{"names":{"username":"2126bb82....9c7780"}}` 200
  }
}

Tauscht Username und den Hex-String gegen eure eigenen Werte aus und speichert die Datei.

Anschließend ladet den Caddy Webserver mit sudo systemctl reload caddy neu und schon sollte eure NIP-05 ID bereit sein.

Wenn ihr mehrere IDs haben möchtet, sieht das folgendermaßen aus:

{
  "names": {
    "username": "2126bb82....9c7780",
    "alice": "a1b2c3d4....abcdef",
    "bob": "e5f6g7h8....123456",
    "satoshi": "9i0j1k2l....fedcba"
  }
}

Zurück zum Blitz⚡Bank Seite

---

Erstellt mit Liebe 🧡 Seit 866520 / 973448

---