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önnte 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:
apt update && apt upgrade -y
-> Ggf. bestätigen mit y und Enter
reboot
-> Kurz warten und dann neu einloggen
2.3 LNbits update
sudo systemctl stop lnbits cd ~/lnbits git pull poetry self update poetry install --only main
LNbits neu starten:
sudo systemctl start lnbits
-> Die Version könnte 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.
2.4 Phoenix Wallet Update
sudo systemctl stop lnbits sudo systemctl stop phoenixd
-> LNbits und Phoenix Daemon wird gestoppt
Neueste Version prüfen: https://github.com/ACINQ/phoenixd/releases
Nachfolgend die Versionsnummern anpassen in Zeile 2 und 3.
cd phoenixd wget https://github.com/ACINQ/phoenixd/releases/download/v0.4.x/phoenix-0.4.x-linux-x64.zip unzip -j phoenix-0.4.x-linux-x64.zip
-> Zweimal mit y und Enter bestätigen
Phoenix und LNbits starten:
sudo systemctl start phoenixd sudo systemctl start 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 sollte 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 Ordern „data“ nur um zu „data.backup“. Damit könnt ihr Not auch noch 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.
adduser backup sudo nano /etc/ssh/sshd_config
AllowUsers backup
Den ssh-Dienst einmal neu starten und dann mit dem neuen User anmelden:
sudo systemctl restart ssh exit
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 und ebenfalls ein Verzeichnis mit dem Namen „backups“ anlegen.
mkdir ~/backups
Testen 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_rsa ~/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_rsa) 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_rsa ~/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.
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. Erweitertes härten des VPS Zugangs
Hinweis: 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. Mach als erstes ein Snapshot eures VPS, damit 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.
5.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
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:\User\User\.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 know_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 einen 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 know_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\axels\.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, in dem ihr euch einmal mit dem Befehl exit ausloggt und dann neu anmeldet. Entweder werdet ihr wie Zauberhand eingeloggt, oder wenn ihr ein Passwortschutz für den Schlüssel vergebe habt, werdet ihr nach dem Passwort zum Entschlüsseln gefragt und dann eingeloggt.
Wichtig: Eure Schlüssel müsst ihr beim root- und beim blitzbank-User hinterlegen. Loggt euch dafür bei beiden einmal ein.
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!
5.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_rsa (bei Windows) 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 setzten:
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 sollte ihr keine Passwortabfrage mehr sehen. Das gilt jetzt für bei Benutzer.
5.3 Login per root-User deaktivieren
Da der root-User an 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.
5.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.
Jetzt den Standard Port 22 in der Firewall (ufw) mit deny schließen und den Status betrachten:
sudo ufw deny 22 comment 'OpenSSH' 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. 😉
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.
Erstellt mit Liebe 🧡 – Block 866520 / 872770
– Lightning ⚡ (er)leben –
Value 4 Value
axelhamburch@ereignishorizont.xyz
