SSH Zugang des Bitcoin-/ Lightning Node sichern

Wenn wir einen Bitcoin / Lightning Node bzw. einen Server betreiben, sind diese Geräte im Normalfall 24 Stunden, 7 Tage die Woche, 365 Tage im Jahr für uns erreichbar. Wir nutzen all die Vorteile eines eigenen Node und unserem eigenen Electrum- / Fulcrumserver.

Diese Geräte sind allerdings auch rund um die Uhr mit dem Internet verbunden damit sie zuverlässig funktionieren. Das birgt Gefahren...!

Um nicht Opfer des erstbesten Script-Kiddies zu werden, ist es unumgänglich uns Gedanken darüber zu machen, wie wir unseren Node vor Angreifern schützen.

Da wir via SSH (secure shell) verschlüsselt mit unserem Node kommmunizieren, kommt diesem Service besondere Aufmerksamkeit zu. Denn Ports welche eine Authentifizierung anbieten (HTTPS, SSH, FTP, SMTP, …) werden auch angegriffen.

Im wesentlichen werden wir als erstes ein paar Basics an unserem SSH Zugang ändern. Diese sind dann schon ein riesen Schritt in die richtige Richtung! Fangen wir an....

Hinweis: Damit wir uns bei Fehlern in der Config nicht aus unserem Node bzw. Server aussperren, lasst das aktive Terminalfenster geöffnet! Die Session und der Login bleibt erhalten, bis wir das Terminal beenden. Zum Testen der Änderungen einfach ein weiteres Terminal öffnen.

Standard SSH Port ändern

Um automatischen SSH Portscans von Angreifern aus dem Weg zu gehen, legen wir den SSH-Dienst, der standardmäßig auf dem TCP-Port 22 horcht, auf einen zufälligen höheren Port. Nehmt einen Port, der in euren Node Konfigs nicht von anderen Services genutzt wird z.B. 43210.

Login zu eurem Node, wechselt in das Verzeichnis /etc/ssh und öffnet die sshd_config (die systemweiter SSH Konfiguration):

sudo nano /etc/ssh/sshd_config
Port 43210

Strg+x und J zum speichern.

Neustart des SSH Servers:

sudo systemctl restart sshd

Macht ein neues Terminal auf und ssh auf euren Node...

ssh user@host -p 43210

Um es uns zu ersparen, bei jedem Login den Port mit angeben zu müssen öffnen wir lokal (auf dem SSH Client) die SSH Config...

nano ~/.ssh/config

Dort tragen wir 4 Zeilen ein:

Host "IP des Node/Server"
Hostname "Name des Node/Server"
User "euren §USER Name des Zugang"
Port 43210

Strg+x speichern und fertig. Beim erneuten Versuch euch per SSH zu verbinden reicht:

"ssh user@host" oder einfach "ssh Hostname des Node"

Beispiel: ssh fussy@mein-node

Damit gehen wir automatisierten SSH-Scans effektiver aus dem Weg.

TCP-Wrapper nutzen mit "/etc/hosts.allow" und "/etc/hosts.deny"

Mit dem TCP-Wrapper haben wir die Möglichkeit, Anfragen an unsere Services wie SSH zu beschränken. TCP-Wrapper nimmt entsprechende Verbindungsanfragen im voraus entgegen und unterbindet oder leitet sie an unseren Dienst weiter. Somit können wir auf einfache Weise bestimmte IP's und Netzwerke ausschließen bzw. zulassen.

Dazu bearbeiten wir die Sperrklauseln /etc/hosts.deny:

sudo nano /etc/hosts.deny

#SSH Zugangssperre Alle außer Lokale
sshd: ALL EXCEPT LOCAL

Strg+x speichern.

Die freigegebenen Adressen kommen in die /etc/hosts.allow:

sudo nano /etc/hosts.allow

#Beispiele für private, erlaubte IP's und Netze. Kann nach belieben angepasst und mehrfach eingetragen werden.

sshd: 192.168.10.123
sshd: 10.10.0.123
sshd: 192.168.178.0/255.255.255.0

Strg+x speichern.

Die Adressen müssen an eure Netzwerkumgebung angepasst werden. Mit diesen beiden Dateien stellen wir sicher, dass nur noch von den direkt angegebenen IP's oder den IP's des Subnetzwerk auf den Node/Server zugegriffen werden kann. Mit "ALL EXCEPT LOCAL" haben wir uns den lokalen Zugriff am Server selbst freigehalten.

Wichtig!! Deaktivieren des direkten Root-Zugangs

Diesen Punkt nicht auslassen!

Direkte Root-Anmeldungen an unserem Node sind nicht zu empfehlen! Wir brauchen es auch nicht, da unser angelegter User jederzeit per "su-command" als Root angemeldet werden kann bzw. jeder Terminal Befehl auch mit dem vorgesetzten "sudo" als Root ausgeführt werden kann.

Wir sperren den Root Login:

sudo nano /etc/ssh/sshd_config
PermitRootLogin no

Wir sperren die PAM Authentifizierung:

UsePAM no
ChallengeResponseAuthentication no

Strg+x speichern und fertig.

Einschränken auf Public-Key-Zugang

Auch diesen Punkt möglichst versuchen umzusetzen!

Um Brute-Force Attacken, auf unser relativ unsichers Passwort Login zu unterbinden, sollte der Passwort Login komplett abgeschaltet werden und die Authentifizierung nur über ein Public-Key-Auth erfolgen.

Hierzu müssen wir uns zuerst ein Schlüsselpaar erstellen. Das tun wir lokal auf unserem Heimrechner/Client.

Voraussetzungen: OpenSSL installieren, z.B. unter Debian/Ubuntu mittels § sudo apt-get install openssl

Um zu prüfen, ob wir schon ein Keypair für unseren lokalen User auf dem Heimrechner bereit haben, checken wir das kurz im Terminal:

ls -la ~/.ssh/*.pub

Falls Schlüüsel gelistet sind bekommen wir folgendes aufgelistet.

id_dsa.pub, id_ecdsa.pub, id_ed25519.pub, id_rsa.pub

Ist das der Fall, überspringen wir den nächsten Schritt.

Falls nicht, erstellen wir unser Key-Pair:

ssh-keygen -t rsa -b 4096 -f /home/"USER"/.ssh/id_rsa

Ausgabe:

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): "nutzt einen PW-Manager und erstellt ein starkes Passwort!"
Enter same passphrase again:

Your identification key has been saved in /<Verzeichnis_zum_Speichern_der_Schlüssel>/id_rsa.
Your public key has been saved in /<Verzeichnis_zum_Speichern_der_Schlüssel>/id_rsa.pub.
The key fingerprint is:
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

Die Passphrase schützt den Zugriff auf den privaten Schlüssel.

Der öffentliche (public) Key befindet sich in der Datei "id_rsa.pub", der private Key in "id_rsa".

Für Windows:

Ihr könnt versuchen im Windows CMD das Schlüsselpaar via OpenSSH zu generieren. OpenSSH wurde irgendwann in Windows 10 integriert... folgenden Befehl im Terminal ausführen:

ssh-keygen -b 4096

Nach "Enter" kommt die Eingabe der Passphrase. Die Passphrase schützt den Zugriff auf den privaten Schlüssel. Verwendet einen Passwortmanager und erzeugt ein starkes Passwort!

Das Key-Pair wird in folgendem Verzeichnis gespeichert.

C:\Users\MyUserName\.ssh id_rsa und id_rsa.pub

Alternativ, falls es dabei Schwierigkeiten gibt, nehmt das Tool Puttygen um Schlüssel für OpenSSH zu erstellen. Sucht euch die passende Version für euer Windows raus.

Schlüssel erstellen:

1. Unter "Parameters" auf "SSH-2-RSA" bzw. "SSH-2-DSA" klicken.

2. Anschließend im Textfeld darunter "4096" eingeben.

3. Auf die Schaltfläche "Generate" klicken.

4. Die Maus bewegen, bis der blaue Balken am rechten Rand angekommen ist.

5. Nach kurzer Zeit hinter "Key Passphrase" und "Confirm Passphrase" die Passphrase eingeben.

Hinweis: Die Passphrase schützt den Zugriff auf den privaten Schlüssel. Verwendet einen Passwortmanager und erzeugt ein starkes Passwort!

6. Auf die Schaltfläche "Save public key" und danach auf "Save private key" klicken. Legt dann im jeweils erscheinenden Dialogfenster fest, wo die Schlüssel gespeichert werden sollen.

Wichtig! ... legt ein Backup eurer Keys an. PW-Manager wie KeypassDX unterstützen das Speichern von Dateien.

Jetzt kopieren wir den Public Key, rsa.pub auf unseren Node/Server in die Datei /home/USER/.ssh/authorized_keys

USER ist wie immer mit eurem Nutzernamen zu ersetzen...

Der schnellste Weg geht mit dem Tool "ssh-copy-id" im lokalen Terminal:

ssh-copy-id username@server/node

Alternativ kann man die Datei auch händisch anlegen:

scp ~/.ssh/id_rsa.pub | ssh USER@HOST "mkdir /home/USER/.ssh; cat >> .ssh/authorized_keys"

Für einen extra Layer an Sicherheit setzen wir die Ordner & Dateirechte von authorized_keys auf

sudo chmod -R 700 ~/.ssh && chmod 600 ~/.ssh/authorized_key

Das verhindert einen Zugriff auf das Verzeichnis und unser Keyfile durch andere User am System.

Anpassen der SSH Config

Wechselt in die ssh config eures Node und setzt diese 2 Zeilen auf:

sudo nano /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no

Strg+x speichern.

Damit wir uns bei einem Fehler jetzt nicht aus unserem Node aussperren, lasst dieses Terminalfenster geöffnet! Die Session und der Login bleibt erhalten, bis wir das Terminal beenden.

Damit unsere Änderungen angewendet werden öffnen wir ein neues Terminal und melden uns mit unserem USER@HOST und dem noch erlaubten Passwort an. Danach restarten wir unseren SSH Server mit:

sudo systemctl restart sshd

Ab hier ist kein Remote Login mehr möglcih außer von eurem USER in Verbindung mit dem richtigen Key!

Jetzt checken wir ob alles geklappt hat. Neues Terminal öffnen und login auf eurem Node/Server via:

ssh User@Host

Im folgenden öffnet sich ein Fenster zur Abfrage der Passphrase (unser neu erstelltes starkes PW).
Nach Eingabe des PW erfolgt der Login zu eurem Node.

Last login: Thu Apr 6 21:04:23 2023 from 192.168.10.123

Falls jetzt Probleme auftreten wie Permission denied oder Fehler im PreAuth haben wir noch unsere aktive Terminalsession, die wir vorhin NICHT geschlossen haben. Dort einfach nochmal in die SSH Config und die Zeile

PasswordAuthentication no

ändern auf...

PasswordAuthentication yes

Danach könnt ihr in Ruhe schauen wo es hängt. Bei Problemen findet ihr immer guten Rat in unserer Telegram Gruppe ;)

Hier gehts zum Teil 2 des Artikels. Inhalt UFW Firewall & Fail2ban

Hat dir der Artikel gefallen? Stay safe... cheers ;)

Onchain / LN Beer: https://coinos.io/FuSsY

Beer over Onion

Lightning only Beer: [email protected]