Extras zur Blitz⚡Bank
Ein Sammelsurium von Tipps, Tricks und Sonstigem zum Phoenix Wallet und LNbits
Hilfe zum Prüfen der Dienste
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"
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.
Systempflege / Backup
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.
System Update
sudo systemctl stop lnbits
-> Das kann bis zu 60 Sekunden dauern
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
LNbits update
sudo systemctl stop lnbits
-> Das kann bis zu 60 Sekunden dauern
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
Phoenix Wallet Update
sudo systemctl stop lnbits
-> Das kann bis zu 60 Sekunden dauern
sudo systemctl stop phoenixd
-> 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 starten:
sudo systemctl start phoenixd
Version prüfen:
~/phoenixd/phoenix-cli getinfo
-> Siehe unten „version“
LNbits starten:
sudo systemctl start lnbits
LNbits Protokoll überprüfen:
sudo journalctl -u lnbits -f --since "2 hour ago"
-> SUCCESS | ✔️ Backend PhoenixdWallet connected and with a balance of 22758000 msat.
Nützliches zu LNbits
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.
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.
Nützliches zu Phoenix
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 lnurlauth Authenticate on a LNURL service sendtoaddress Send to a Bitcoin address closechannel Close channel
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.
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..
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.
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 stellt sicher, dass der private Schlüssel zu dem öffentlichen Schlüssel passt. 3. Wenn sie zusammenpassen, wirst du angemeldet. Das Besondere ist, dass dieses Verfahren sicher ist, weil nur derjenige, der den passenden privaten Schlüssel hat, sich anmelden kann. Da der private Schlüssel geheim bleibt und niemals gesendet wird, ist die Wahrscheinlichkeit eines Hackangriffs viel geringer als bei der Verwendung eines Passworts.
Ein Schlüsselpaar könnt ihr auf eurem Rechner sehr einfach selbst generieren. Öffnet dazu eure Befehlszeilen Terminal so als wenn ihr euch einloggen wollt dann generiert mit folgenden Befehl ein Schlüsselpaar:
ssh-keygen
Als erstes werdet ihr gefragt wo ihr das Schlüsselpaar ablegen wollt. Wenn ihr einfach ENTER drückt, übernimmt er den in Klammern vorgeschlagenen Pfad und Dateiname. Dann kommt die „Enter passphrase“ Abfrage. Hier könnt ihr den Schlüssel nochmal extra 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, ich braucht aber nicht mehr das Passwort für den User zum anmelden. Die Passphrase ist nicht notwendig, bietet nur etwas mehr Sicherheit. Ihr dürft aber weder die Schlüsseldatei noch die Passphrase verloren bringen. Anbei ein Bild zur SSH-Schlüsselpaare Generierung auf einem Windows 11 Rechner.
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. Installiert ihr euren Server also mal neu, hat er einen neues Schlüsselpaar generiert und ihr bekommt ein Warnmeldung:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)!
In diesem Fall könnt ihr beruhigt sein, da ihr jetzt ja wisst, wieso die Meldung kommt. 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.
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
-> Hier den Inhalt des öffentlichen Schlüssel id_ed25519.pub
einfügen und dann 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 euren verschlüsselten Schlüssel, einfach Enter drückt, kommt als zweite Option die Passwortabfrage. Probiert es aus!
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.
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.
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@yourIPaddres
-> 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
Einmal neu starten, exit
und neu einloggen, um den Zugang zu prüfen, in der Hoffnung, dass ihr euch nicht selbst ausgesperrt habt. 😉
sudo systemctl restart ssh
Damit habt ihr dem Server eine große Portion mehr Sicherheit hinzugefügt. 💪 Ihr habt nur kleines verstecktes Türchen offen gelassen. Bewahrt den Zugang und das Wissen darüber gut auf.
Erstellt mit Liebe 🧡 – Block 866520 / 869026
– Lightning ⚡ (er)leben –
Value 4 Value
axelhamburch@ereignishorizont.xyz