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.

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.

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.

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“.

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.

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

-> 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.

Zurück zum Blitz⚡Bank Seite

Erstellt mit Liebe 🧡 – Block 866520 / 870554

– Lightning ⚡ (er)leben –

Value 4 Value
axelhamburch@ereignishorizont.xyz