KeyHelp: Datenbank-Fernzugriff sicher freigeben oder per SSH-Tunnel ersetzen

Manche Werkzeuge wollen direkt auf die Datenbank: HeidiSQL oder DBeaver am Arbeitsplatz, ein Reporting-Tool, ein zweiter Server. KeyHelp kann den Datenbankserver dafür öffnen, doch dabei greifen drei Ebenen ineinander: die Einstellung im Panel, die Firewall und die Rechte des einzelnen Datenbankbenutzers. Diese Anleitung zeigt alle drei, prüft mit echten Verbindungen, was jede Ebene bewirkt, und stellt die sicherere Alternative vor: den SSH-Tunnel, bei dem Port 3306 geschlossen bleibt. Sie richtet sich an Administratoren eines Servers wie in KeyHelp installieren und absichern. Getestet haben wir mit KeyHelp 26.1.1 und MariaDB 10.11 auf Debian 12, den externen Client haben wir in der Test-VM in einem eigenen Netzwerk-Namespace mit Adressen aus 198.51.100.0/24 nachgebildet.

Voraussetzungen

• Ein KeyHelp-Server mit Administrator-Zugang. Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15 mit MariaDB 10.11.18.
• Eine Kundendatenbank, im Beispiel kunde1_db des Kunden kunde1.
• Die feste öffentliche IP des Rechners, der zugreifen soll. Im Beispiel 198.51.100.20.
• Für den Tunnel SSH-Zugang für das Kundenkonto und ein SSH-Schlüssel auf dem Client.

Schritt 1: Ausgangslage prüfen

Ab Werk ist der Fernzugriff aus. MariaDB ist auf 127.0.0.1 gebunden, und die KeyHelp-Firewall hat eine eigene Regel „MariaDB / MySQL“ mit der Aktion „Verweigern“ für TCP 3306:

mysql -e "SELECT @@bind_address, @@skip_networking, @@port"
iptables -S INPUT | grep 3306
ss -ltnp | grep 3306

127.0.0.1	0	3306
-A INPUT -p tcp -m tcp --dport 3306 -j DROP
LISTEN 0      4096                                    *:3306             *:*    users:(("mariadbd",pid=694,fd=5),("systemd",pid=1,fd=62))

Die letzte Zeile ist bemerkenswert: Trotz bind-address = 127.0.0.1 lauscht Port 3306 auf allen Adressen, und zwar über systemd. Grund ist die Socket-Aktivierung, die auf dem Testsystem aktiv war:

systemctl cat mariadb.socket

ListenStream=@mariadb
ListenStream=/run/mysqld/mysqld.sock
ListenStream=3306

Den Port nach außen sperrt damit allein die Firewall. Ein Verbindungsversuch vom nachgebildeten Client (Netzwerk-Namespace, siehe Einleitung) lief ins Leere:

443 offen
3306: keine Verbindung (rc=124)

Verifizieren: Die Firewall-Regel „MariaDB / MySQL“ steht unter „Sicherheit“, „Firewall“ mit „Verweigern“ und „TCP: 3306“. Vom Client ist 3306 nicht erreichbar, Port 443 schon.

Schritt 2: Fernzugriff im Panel erlauben

Öffnen Sie „Konfiguration“, „Datenbank-Server“. Der Hinweistext erklärt die Reihenfolge selbst: erst den Server öffnen, dann den Port in der Firewall, dann den Benutzern das Recht geben. Aktivieren Sie „Fernzugriff erlauben“ und speichern Sie.

KeyHelp schreibt dafür eine eigene Datei und startet MariaDB neu:

cat /etc/mysql/mariadb.conf.d/99-keyhelp.cnf

# Settings managed by KeyHelp
[mysqld]
# Enable remote access
bind-address = *

Die Firewall ändert KeyHelp dabei nicht. Die Regel „Verweigern“ blieb bestehen, ein Verbindungsversuch scheiterte weiter:

-A INPUT -p tcp -m tcp --dport 3306 -j DROP
3306: keine Verbindung (rc=124)

Verifizieren: mysql -e "SELECT @@bind_address" liefert *. Der Port bleibt für den Client zu, bis Sie die Firewall anpassen.

Schritt 3: Firewall nur für Ihre IP öffnen

Öffnen Sie „Sicherheit“, „Firewall“ und klicken Sie auf „Bearbeitungsmodus aktivieren“. Mit „Regel hinzufügen“ legen Sie eine Regel an: „Name“ frei wählbar, „Richtung“ „Eingehender Traffic“, „Aktion“ „Zulassen“, „TCP-Ports“ 3306 und unter „Quellen“ nur die IP-Adresse des Clients. Die bestehende Regel „Verweigern“ lassen Sie stehen.

Nach „Speichern“ meldet KeyHelp „Die Firewall-Regel wurde hinzugefügt.“, wirksam wird sie aber erst mit „Änderungen übernehmen“. Die neue Regel stand im Test oben in der Liste, vor der Verweigern-Regel. Das ist wichtig, denn laut Hinweis auf der Seite gilt: „Sobald eine Regel zutrifft, werden die folgenden Regeln nicht mehr ausgewertet.“

11:-A INPUT -s 198.51.100.20/32 -p tcp -m tcp --dport 3306 -j ACCEPT
24:-A INPUT -p tcp -m tcp --dport 3306 -j DROP

Verifizieren: Vom erlaubten Client ist der Port erreichbar, von einer anderen Adresse (198.51.100.21) nicht:

3306 offen
ERROR 2002 (HY000): Can't connect to server on '198.51.100.1' (110)

Schritt 4: Dem Datenbankbenutzer den Host erlauben

Sobald der Fernzugriff unter „Datenbank-Server“ erlaubt ist, erscheint beim Kunden unter „Datenbank bearbeiten“ der Bereich „Fernzugriff“ mit drei Optionen: „Nur lokale Verbindungen zulassen.“, „Verbindungen von beliebigen Hosts zulassen.“ und „Erlaubt Remote-Verbindungen von einem oder mehreren angegebenen Hosts.“ Im Kundenkonto gibt es zudem unter dem Reiter „Berechtigungen“ die Option „Datenbank-Fernzugriff“. Sie war im Test ab Werk angehakt, ohne sie haben wir nicht getestet.

Wählen Sie die dritte Option und tragen Sie die IP ein. KeyHelp legt dafür einen zweiten MariaDB-Benutzer mit gleichem Namen und anderem Host an, mit allen Rechten auf die Datenbank:

kunde1_db	198.51.100.20
kunde1_db	localhost
GRANT ALL PRIVILEGES ON `kunde1\\_db`.* TO `kunde1_db`@`198.51.100.20`

Die Option „Verbindungen von beliebigen Hosts zulassen.“ haben wir nicht getestet.

Verifizieren: Vom Client mit dem Kundenpasswort anmelden:

mysql -h 198.51.100.1 -u kunde1_db -p -e "SELECT CURRENT_USER(), @@hostname"

kunde1_db@198.51.100.20	server.example.de

Ein falsches Passwort und der Benutzer root werden abgewiesen:

ERROR 1698 (28000): Access denied for user 'root'@'198.51.100.20'
ERROR 1045 (28000): Access denied for user 'kunde1_db'@'198.51.100.20' (using password: YES)

Schritt 5: Besser ein SSH-Tunnel

Ein Tunnel führt die Datenbankverbindung durch SSH. Port 3306 bleibt in der Firewall zu, Fernzugriff im Panel bleibt aus, und es gibt keinen zusätzlichen Datenbankbenutzer für eine fremde IP. Voraussetzung ist SSH für das Kundenkonto. Der Administrator setzt dazu im Kundenkonto unter „Berechtigungen“ den Haken „SSH“. KeyHelp warnt dort: „Achtung! Der Kunde ist nicht auf sein Stammverzeichnis beschränkt.“ Die „Eingeschränkte SSH-Umgebung“ ist laut Panel ein „Pro-Feature“. In der sshd_config steht für die Gruppe keyhelp_chroot zudem AllowTCPForwarding no, ein Tunnel dürfte dort also nicht funktionieren. Getestet haben wir das mangels Professional Edition nicht.

Nach dem Speichern hatte kunde1 die Shell /bin/bash. Wir haben den öffentlichen Schlüssel des Clients in /home/users/kunde1/.ssh/authorized_keys eingetragen und vom Client aus den Tunnel gestartet:

ssh -i ~/.ssh/tunnel_key -f -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 kunde1@198.51.100.1
mysql -h 127.0.0.1 -P 13306 -u kunde1_db -p -e "SELECT CURRENT_USER(), USER(); SHOW DATABASES;"

Tunnel steht
CURRENT_USER()	USER()
kunde1_db@localhost	kunde1_db@localhost
Database
information_schema
kunde1_db

Die Anmeldung erfolgt als kunde1_db@localhost, also mit dem normalen lokalen Benutzer. Grafische Clients wie HeidiSQL oder DBeaver haben wir nicht getestet.

Verifizieren: Im Auth-Log steht die SSH-Anmeldung des Clients, die Datenbank meldet den lokalen Benutzer:

Accepted publickey for kunde1 from 198.51.100.21 port 49764 ssh2: ED25519

Die Adresse 198.51.100.21 hatte keine Firewall-Freigabe für 3306, der Tunnel lief über SSH (Port 22).

Schritt 6: Fernzugriff wieder schließen

Deaktivieren Sie „Fernzugriff erlauben“ wieder. KeyHelp schreibt bind-address = 127.0.0.1, und beim Kunden verschwindet der Bereich „Fernzugriff“ aus „Datenbank bearbeiten“. Zwei Dinge blieben im Test aber bestehen:

# Disable remote access
bind-address = 127.0.0.1
kunde1_db	198.51.100.20
kunde1_db	localhost
LISTEN 0      4096                                      *:3306             *:*          

Der externe Benutzer kunde1_db@198.51.100.20 wurde nicht gelöscht, und Port 3306 lauschte wegen der Socket-Aktivierung weiter auf allen Adressen. Mit der noch vorhandenen Firewall-Regel klappte die Anmeldung von außen deshalb weiterhin:

Direkt von 198.51.100.20 bei bind-address 127.0.0.1:
CURRENT_USER()
kunde1_db@198.51.100.20

Im Test hat folgende Abhilfe gewirkt: die Socket-Aktivierung abschalten und MariaDB neu starten. Danach lauschte MariaDB nur noch auf 127.0.0.1, der Verbindungsversuch von 198.51.100.20 wurde trotz Firewall-Freigabe und noch vorhandenem externen Benutzer abgewiesen. Die lokale Anmeldung funktionierte weiter, der SSH-Tunnel nach einem Neuaufbau ebenfalls:

systemctl disable --now mariadb.socket
systemctl restart mariadb

LISTEN 0      90                                127.0.0.1:3306       0.0.0.0:*    users:(("mariadbd",pid=4099,fd=18))
ERROR 2002 (HY000): Can't connect to server on '198.51.100.1' (115)

Das ist ein Eingriff außerhalb von KeyHelp. Ob ein KeyHelp- oder Paket-Update die Socket-Aktivierung wieder einschaltet, haben wir nicht geprüft. Kontrollieren Sie deshalb nach Updates ss -ltnp | grep 3306.

Räumen Sie zusätzlich die Firewall-Freigabe aus Schritt 3 und den externen Benutzer auf. Im Panel gab es für den Benutzer nach dem Abschalten keine Option mehr. Laut MariaDB-Dokumentation entfernt DROP USER ein Konto samt Rechten, also hier DROP USER 'kunde1_db'@'198.51.100.20'; als root. Beides, das Löschen der Firewall-Regel und DROP USER, haben wir im Test nicht ausgeführt.

Verifizieren: ss -ltnp | grep 3306 zeigt nur noch 127.0.0.1:3306 ohne systemd, ein Verbindungsversuch vom Client endet mit „Can't connect to server“.

Typische Fehler

„Ungültige Angabe im Feld Quellen.“ So reagierte die Firewall auf die ungültige Adresse 198.51.100.300.

Regel gespeichert, aber ohne Wirkung. Im Bearbeitungsmodus erscheint der Hinweis „Bitte beachten Sie, dass Änderungen erst wirksam werden, sobald Sie die Schaltfläche Änderungen übernehmen betätigen.“ Erst danach meldet KeyHelp „Die Firewall-Regeln wurden erfolgreich übernommen.“

„Can't connect to server“ mit (110). Der Client wartet bis zur Zeitüberschreitung, weil die Firewall die Pakete verwirft. Prüfen Sie, ob die Quell-IP stimmt.

Hostnamen statt IP. Beim Kunden nahm das Feld für erlaubte Hosts auch büro.example ohne Fehlermeldung an und legte daraus einen Benutzer an. Tragen Sie IP-Adressen ein.

„Access denied for user 'root'“. So wurde im Test ein Anmeldeversuch als root vom Client abgewiesen. Melden Sie sich mit dem Datenbankbenutzer des Kunden an.

Häufige Fragen

Reicht die Firewall-Regel allein?

Für eine Neueinrichtung nein: Der Datenbankbenutzer braucht zusätzlich die Freigabe für die externe IP (Schritt 4). Ein einmal angelegter externer Benutzer blieb im Test aber auch nach dem Abschalten bestehen (Schritt 6). Umgekehrt war im Test ohne Eingriff außerhalb von KeyHelp die Firewall die einzige Ebene, die den Port wirklich sperrte.

Ist die Verbindung über Port 3306 verschlüsselt?

Das haben wir nicht geprüft. Der SSH-Tunnel verschlüsselt die Verbindung in jedem Fall.

Kann ich IP-Bereiche freigeben?

Laut Hinweis im Formular nimmt das Feld „Quellen“ der Firewall „eine oder mehrere IP-Adressen oder Netzwerkmasken“ an. Getestet haben wir eine einzelne Adresse.

Braucht der Kunde für den Tunnel volles SSH?

Ohne Professional Edition ja: Im Test war nur die SSH-Berechtigung mit dem Hinweis möglich, dass der Kunde nicht auf sein Stammverzeichnis beschränkt ist. Wägen Sie ab, ob Sie das dem Kunden geben.

Testumfang

Wir haben auf KeyHelp 26.1.1 Fernzugriff, Firewall-Regel und Host-Freigabe je Datenbank eingerichtet und von einem nachgebildeten Client mit zwei IP-Adressen geprüft, außerdem einen SSH-Tunnel. Der Client war eine Simulation: ein Netzwerk-Namespace auf derselben VM, per veth-Paar mit Adressen aus 198.51.100.0/24 angebunden. Auffällig: Port 3306 lauschte durch die Socket-Aktivierung von MariaDB im Grundzustand und nach dem Abschalten unabhängig von bind-address auf allen Adressen. Nicht geprüft haben wir echte Internetverbindungen, TLS auf 3306, grafische Clients, die Option „beliebige Hosts“, die Professional Edition, das Löschen von Firewall-Regel und externem Benutzer sowie das Verhalten nach Updates. Prüfen Sie Ihren Server mit ss -ltnp.

Fazit

KeyHelp macht den Fernzugriff auf Datenbanken mit wenigen Klicks möglich, verteilt ihn aber auf drei Stellen, und keine räumt beim Abschalten vollständig auf. Verlassen Sie sich nicht auf bind-address, sondern auf eine Firewall-Regel mit fester Quell-IP, prüfen Sie ss -ltnp | grep 3306 auf die Socket-Aktivierung, und löschen Sie Regel und externen Benutzer, wenn Sie den Zugang nicht mehr brauchen. Wo es geht, ist der SSH-Tunnel die bessere Lösung: kein offener Datenbankport, verschlüsselt und mit dem normalen lokalen Benutzer.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• MariaDB / MySQL installieren und absichern
• Linux-Server absichern: UFW-Firewall und Fail2ban
• Keyweb: KeyHelp, alle Funktionen im Überblick
• KeyHelp Knowledge Base: MySQL Datenbanken