MariaDB per SSH Tunnel erreichen: lokale Ports und Rechte

Der Tunnel verbindet zwei getrennte Zugänge

Ein SSH Tunnel leitet eine Verbindung von einem lokalen Port durch eine verschlüsselte SSH Sitzung zu einem Ziel auf der anderen Seite. Bei einer Datenbank bedeutet das: Das Verwaltungsprogramm auf Ihrem Rechner verbindet sich mit einem lokalen Port; der SSH Server stellt die Verbindung zum Datenbankziel her. Der Datenbankport muss dafür nicht allgemein im Internet freigegeben sein. Trotzdem sind zwei Anmeldungen beteiligt. Der SSH Zugang erlaubt den Transport, der Datenbankzugang erlaubt die Arbeit an den Daten. Ein erfolgreicher SSH Login ist deshalb noch kein Beleg für erlaubtes Forwarding und erst recht keine Berechtigung zum Lesen oder Ändern beliebiger Datenbanken.

Diese Trennung ist für Plesk Kunden besonders wichtig. Eine Plattform kann SSH und MariaDB unterstützen, während ein bestimmtes Abo keinen Tunnel erlaubt. Ein eingeschränkter Benutzer kann zudem eine andere Shell oder andere Richtlinien haben als ein Administrator. Prüfen Sie den tatsächlich angebotenen Zugang und fragen Sie den Anbieter konkret nach lokalem Port Forwarding zu dem benötigten Datenbankziel. Eine allgemeine Aussage SSH ist verfügbar beantwortet diese Frage nicht vollständig. Der Ratgeber zu Hosting Zuständigkeiten hilft, technische Möglichkeit und verbindliche Freigabe für die konkrete Umgebung voneinander zu unterscheiden und schriftlich brauchbar festzuhalten.

Das Ziel wird vom SSH Server aus gesehen

Die OpenSSH Beschreibung von Local Forwarding erklärt die Bedeutung der Zieladresse. Bei einem Tunnel zu 127.0.0.1 auf der entfernten Seite meint diese Adresse den SSH Server, nicht Ihren eigenen Rechner. Das passt, wenn MariaDB auf genau diesem Host über TCP an der Loopbackadresse erreichbar ist. Liegt die Datenbank dagegen auf einem getrennten Host, muss das Ziel aus Sicht des SSH Servers passend gewählt und erlaubt sein. Zeichnen Sie diesen Weg kurz auf. Ein falsch verstandenes localhost ist eine häufige Ursache dafür, dass die SSH Sitzung steht, die Datenbankverbindung aber sofort abgewiesen wird.

Auch lokal ist die Bindung wichtig. Wenn der Tunnel ausschließlich von Ihrem eigenen Rechner verwendet werden soll, binden Sie ihn ausdrücklich an 127.0.0.1. Eine Bindung an alle Schnittstellen kann den weitergeleiteten Zugang für andere Geräte erreichbar machen. Dafür gibt es in speziellen Umgebungen Gründe, aber es ist eine andere Betriebsentscheidung. Für eine normale Verwaltungssitzung ist die enge lokale Grenze leichter zu prüfen. Wählen Sie einen freien lokalen Port, zum Beispiel 3307, wenn 3306 bereits durch eine lokale Datenbank belegt ist. Diese Nummer gehört nur zum lokalen Ende und verändert den entfernten MariaDB Dienst nicht.

Ein Beispiel mit klaren Platzhaltern

ssh -N -L 127.0.0.1:3307:127.0.0.1:3306   -o ExitOnForwardFailure=yes   dbadmin@ssh.example.org

Der Name dbadmin und die Domain im Beispiel sind Platzhalter für einen freigegebenen Zugang. Die Option N startet keinen entfernten Befehl; die Sitzung dient hier nur dem Tunnel. ExitOnForwardFailure hilft, einen Fehler beim Aufbau des lokalen Forwardings zu erkennen. Sie beweist jedoch nicht, dass jeder spätere Verbindungsversuch zum Datenbankziel erfolgreich ist. Dieses Ziel wird beim Datenbankaufruf geprüft. Für die erste Diagnose ist ein sichtbarer Vordergrundprozess praktisch, weil Fehler direkt erkennbar bleiben. Beenden Sie die Sitzung nach der Arbeit bewusst. Ein unbeobachteter Hintergrundtunnel kann später zu Verwechslungen führen, wenn derselbe lokale Port scheinbar bereits belegt ist.

Wenn der SSH Dienst einen freigegebenen abweichenden Port verwendet, ergänzen Sie den bekannten Port mit der passenden Option. Probieren Sie nicht wahllos Ports aus und akzeptieren Sie keinen unbekannten Hostschlüssel blind. Prüfen Sie den Fingerabdruck über einen vertrauenswürdigen Weg des Anbieters. Ein Tunnel verschlüsselt die Verbindung, aber die Verschlüsselung zum falschen Gegenüber löst das Identitätsproblem nicht. Für wiederkehrende Arbeit kann eine klar benannte lokale SSH Konfiguration sinnvoll sein. Sie sollte den Zielhost und die benötigten Optionen verständlich halten, ohne Passwörter im Klartext zu speichern. Der Name des Eintrags hilft zugleich, ähnliche produktive und testweise Verbindungen auseinanderzuhalten.

Serverrichtlinien gezielt klären

Die OpenSSH Serverdokumentation beschreibt unter anderem AllowTcpForwarding und PermitOpen. Damit kann der Hostbetrieb Forwarding erlauben und die zulässigen Ziele begrenzen. Auch weitere Richtlinien für Benutzer oder Schlüssel können eine Rolle spielen. Als Kunde sollten Sie diese Regeln nicht global verändern, selbst wenn Sie irgendwo eine Beispielkonfiguration gefunden haben. Fragen Sie nach dem benötigten lokalen Forwarding und dem konkreten Ziel. Für einen Betreiber mit administrativer Zuständigkeit gilt dieselbe Begrenzung: Eine domainspezifische Anforderung rechtfertigt keine pauschale Öffnung aller SSH Benutzer und aller Ziele. Nutzen Sie die schmalste passende Freigabe und prüfen Sie sie mit dem vorgesehenen Konto.

Ein Hinweis wie administratively prohibited bedeutet eine andere Fehlerklasse als connection refused am Datenbankziel. Im ersten Fall kann eine SSH Richtlinie den Kanal blockieren. Im zweiten Fall ist der Transport möglicherweise erlaubt, aber der Zielport wird nicht bedient. Lesen Sie deshalb den genauen Fehler und halten Sie fest, wann er erscheint. Ein lokaler Portkonflikt entsteht wiederum vor der entfernten Datenbankprüfung. Diese Reihenfolge hilft, die zuständige Person zu finden. Der SSH Betrieb prüft Zugang und Kanalregeln; der Datenbankbetrieb prüft Listener und Rechte. Eine klare Meldung verhindert, dass beide Seiten denselben allgemeinen Satz kein Zugriff wiederholt beantworten.

MariaDB muss den richtigen TCP Weg anbieten

Die MariaDB Anleitung zu entfernten Verbindungen behandelt Listener und bind address. Für das gezeigte Tunnelziel reicht ein erreichbarer TCP Listener auf der entfernten Loopbackadresse. Ein allgemeines Öffnen auf allen Schnittstellen ist dafür nicht nötig. Wenn MariaDB ausschließlich über einen Unix Socket angesprochen wird, passt das TCP Beispiel jedoch nicht unverändert. Prüfen Sie den tatsächlichen Dienstweg, bevor Sie eine breite Netzwerkfreigabe verlangen. Der Tunnel soll einen vorhandenen kontrollierten Weg transportieren. Er ist kein Grund, die Datenbank zusätzlich öffentlich erreichbar zu machen oder eine bestehende Sicherheitsgrenze ohne Not zu erweitern.

Das Datenbankkonto wird aus Sicht des entfernten Dienstes geprüft. Der Netzwerkursprung kann dabei anders sein als bei einer normalen Anmeldung aus einem lokalen Terminal. Deshalb muss die passende Kontozuordnung und Authentifizierung zum tatsächlichen TCP Weg geprüft werden. Verwenden Sie ein eigenes Konto mit den benötigten Rechten, etwa lesend für einen Bericht. Ein umfangreicher Administratorzugang ist für eine einzelne Datenbankaufgabe oft unnötig. Halten Sie fest, welche Datenbank und welche Aktionen erlaubt sein sollen. Der Ratgeber zu begrenzten Rollen zeigt, wie sich Rechte am Arbeitsauftrag orientieren und später überprüfbar zurücknehmen lassen.

Den Datenbanktest explizit über TCP ausführen

mariadb --protocol=TCP --host=127.0.0.1 --port=3307   --user=report_user --password

Das Beispiel fragt nach dem Passwort, statt es als Argument in die Kommandozeile zu schreiben. Der Benutzername ist erneut ein Platzhalter. Der ausdrückliche TCP Weg ist wichtig, weil manche Datenbankclients bei localhost einen lokalen Socket wählen. Dann wird der Tunnel gar nicht genutzt, obwohl die Oberfläche eine vertraute Adresse zeigt. In einer grafischen Anwendung setzen Sie Host und Port entsprechend und prüfen Sie, ob sie zusätzlich einen eigenen SSH Modus besitzt. Verwenden Sie entweder den bereits geöffneten Tunnel oder den integrierten Tunnel bewusst. Zwei gleichzeitig eingerichtete Wege erhöhen die Chance auf Portkonflikte und erschweren die Erklärung eines Fehlers.

Beginnen Sie nach dem Login mit einer harmlosen Leseprüfung. Kontrollieren Sie den erwarteten Server und die benötigte Datenbank, bevor Sie Daten verändern. Gerade bei mehreren Umgebungen kann ein funktionierender Tunnel zum falschen Ziel führen. Für eine Exportaufgabe lesen Sie zunächst einen kleinen bekannten Bereich und prüfen Sie das Ergebnis. Für Schreibarbeit braucht es einen passenden Sicherung und einen Rückweg. Der Ratgeber zum Restore Test ergänzt diese Vorbereitung. Ein Datenbankprogramm kann sehr mächtige Aktionen anbieten; die erfolgreiche Verbindung ist keine automatische Freigabe, sie alle in einer produktiven Umgebung auszuführen.

Fehler mit einer festen Reihenfolge lesen

Prüfen Sie zuerst, ob der SSH Login funktioniert und ob der richtige Host bestätigt ist. Prüfen Sie dann den Aufbau des lokalen Ports. Erst danach kommt die entfernte Erreichbarkeit von MariaDB und zuletzt deren Anmeldung. Halten Sie jede Ebene getrennt fest. Ein Fehler bei der Datenbankauthentifizierung beweist bereits mehr über den Transport als ein reiner Timeout, ist aber noch kein nutzbarer Zugang. Umgekehrt sagt eine erfolgreiche SSH Sitzung nichts über die Datenbankrechte. Wenn Sie den Anbieter kontaktieren, nennen Sie diese erreichte Grenze. Damit kann der Support direkt am nächsten offenen Schritt ansetzen, ohne die gesamte Kette von vorn zu erraten.

Zusätzliche SSH Diagnoseausgaben können hilfreich sein, müssen aber geschützt behandelt werden. Sie können interne Namen, Wege und Details zu verwendeten Schlüsseln zeigen. Sammeln Sie nur das für den Fehler nötige Material und entfernen Sie vertrauliche Angaben vor einer breiteren Weitergabe. Passwörter und private Schlüssel gehören niemals in einen Fehlerbericht. Notieren Sie außerdem, ob der Tunnel im Vordergrund oder über ein vorhandenes Verbindungsprofil lief. Ein älterer Hintergrundprozess kann denselben lokalen Port halten und zu einem anderen Ziel führen. Das saubere Beenden aller eigenen Testverbindungen gehört deshalb zur Diagnose, ohne fremde Sitzungen oder Prozesse auf dem Rechner ungezielt zu stoppen.

Lange Aufgaben und Verbindungsabbrüche bedenken

Ein Tunnel kann während einer langen Sitzung unterbrochen werden. Ein schlafender Laptop, ein wechselndes Netz oder eine getrennte VPN Verbindung kann den Weg beenden. Planen Sie längere Exporte deshalb mit einer klaren Erwartung an Laufzeit und Ergebnis. Prüfen Sie nach einem Abbruch, ob eine Datei vollständig ist und ob die entfernte Aufgabe weiterlief oder endete. Starten Sie Schreibvorgänge nicht mehrfach auf Verdacht. Für dauerhafte wiederkehrende Arbeit kann ein serverseitiger Job besser geeignet sein als eine vom eigenen Laptop abhängige Verbindung. Das ist eine Entscheidung über den Ablauf, die mit Rechten, Schutz und Überwachung zusammen betrachtet werden muss.

Für eine normale Verwaltungssitzung reicht häufig ein kurzlebiger Tunnel mit bewusstem Start und Ende. Prüfen Sie nach dem Schließen, dass der lokale Port nicht mehr lauscht. Entfernen Sie temporäre Zugangsdaten, soweit sie nur für diese Aufgabe erstellt wurden, oder entziehen Sie ihre Rechte nach dem vereinbarten Zeitraum. Halten Sie die Arbeit im Betriebsprotokoll fest: Ziel, Konto, Zweck, Zeitpunkt und Ergebnis. Die Passwörter selbst stehen dort nicht. Diese Form ermöglicht eine spätere Prüfung, ob ein Zugang noch benötigt wird. Sie hilft auch, mehrere ähnlich benannte Datenbankkonten voneinander zu unterscheiden und versehentlich dauerhaft offene Verwaltungswege zu vermeiden.

Die Zusage für den konkreten Host bleibt entscheidend

Eine seriöse Antwort zur Machbarkeit enthält den genauen Umfang. Technisch kann OpenSSH lokale TCP Verbindungen weiterleiten, und MariaDB kann passende Verbindungen annehmen. Ob Ihr Abo dies erlaubt, hängt von Zugriff, Richtlinien und Zielkonfiguration ab. Verlangen Sie daher keine allgemeine Produktzusage aus einem funktionierenden Beispiel. Lassen Sie für den eigenen Host den vorgesehenen Benutzer und den Datenbankweg prüfen. Falls ein Anbieter nur einen anderen sicheren Zugangsweg anbietet, beurteilen Sie ihn am konkreten Bedarf. Für gelegentliche Datenpflege kann ein geschütztes Verwaltungswerkzeug ausreichen; für automatisierte Exporte gelten andere Anforderungen an Wiederholung, Rechte und Fehlerbeobachtung.

Ein nutzbarer MariaDB Tunnel ist ein geprüfter Transportweg plus ein passend berechtigtes Datenbankkonto. Das Beispiel liefert einen Startpunkt, aber die Abnahme erfolgt mit der eigenen Umgebung. Dokumentieren Sie die bestätigten Teile und lassen Sie fehlende Hostfreigaben ausdrücklich offen. Nach der Aufgabe wird der Tunnel geschlossen und der verbleibende Zugang geprüft. So entsteht ein eng begrenzter Verwaltungsweg, der keine allgemeine Datenbanköffnung im Internet benötigt. Der praktische Nutzen liegt in der klaren Grenze: Ein lokales Werkzeug kann am richtigen Ziel arbeiten, während SSH Identität, Forwardingregel und Datenbankrechte jeweils ihre eigene Rolle behalten und getrennt überprüft werden können.