SSL/TLS und SSH-Tunnel
Zwei verschiedene Probleme, zwei verschiedene Reiter im Verbindungsdialog. SSL/TLS verschlüsselt die Datenbankverbindung selbst. Ein SSH-Tunnel trägt eine unverschlüsselte Verbindung durch einen Server, dem Sie ohnehin vertrauen.
Beides lässt sich zugleich verwenden.
SSL/TLS
Cloud-Datenbanken — AWS RDS, Supabase, PlanetScale, Azure SQL — verlangen es in der Regel.
Setzen Sie den Haken bei SSL/TLS aktivieren und wählen Sie einen Modus:
| Modus | Wirkung |
|---|---|
| Deaktivieren | Keine Verschlüsselung. Nicht empfohlen |
| Bevorzugen | SSL nutzen, wenn der Server es unterstützt, sonst unverschlüsselt |
| Erfordern | Immer SSL, aber ohne Prüfung des Zertifikats |
| CA prüfen | SSL mit Prüfung des Zertifikats gegen die CA |
| Vollständige Prüfung | SSL, Prüfung der CA und des Hostnamens |
Bei SQL Server heißt dieselbe Einstellung Verschlüsselungsstufe.
Zertifikate
Drei optionale Dateipfade erlauben eigenes Material:
- CA-Zertifikat — nötig für CA prüfen und Vollständige Prüfung, wenn der Server eine private CA verwendet.
- Client-Zertifikat und Privater Schlüssel — für Server, die gegenseitiges TLS verlangen.
Selbstsignierte Zertifikate akzeptieren überspringt die Zertifikatsprüfung vollständig. Damit läuft ein Entwicklungsrechner in Sekunden, und der Schutz, für den TLS da ist, ist weg — lassen Sie das bei einer Produktionsverbindung nicht eingeschaltet.
SSH-Tunnel
Mit einem Tunnel verbindet sich NabuSQL zuerst zum SSH-Server und leitet die Datenbankverbindung darüber. So erreichen Sie eine Datenbank, die auf einem entfernten Rechner nur auf localhost lauscht.
Host und Port werden auf dem SSH-Server aufgelöst
Host und Port im Reiter Grundeinstellungen werden aus Sicht des SSH-Servers gelesen. Für eine Datenbank auf demselben Rechner wie der SSH-Server bedeutet das localhost und den üblichen Datenbankport — nicht die öffentliche Adresse des Servers.
Setzen Sie den Haken bei SSH-Tunnel aktivieren und füllen Sie aus:
- Host, Port und Benutzer des SSH-Servers.
- Authentifizierung: Passwort oder Schlüssel.
- Für die Schlüsselauthentifizierung: den Pfad zur privaten Schlüsseldatei und eine Passphrase, falls der Schlüssel verschlüsselt ist.
Ein durchgerechnetes Beispiel
Ein PostgreSQL-Server auf db.example.com nimmt SSH an, aber die Datenbank lauscht nur auf 127.0.0.1:5432:
| Reiter | Feld | Wert |
|---|---|---|
| Grundeinstellungen | Host | 127.0.0.1 |
| Grundeinstellungen | Port | 5432 |
| SSH-Tunnel | Host | db.example.com |
| SSH-Tunnel | Port | 22 |
| SSH-Tunnel | Benutzer | Ihr SSH-Benutzer |
Fehlerbehebung
Connection refused durch den Tunnel — der Datenbank-Host wird auf dem SSH-Server aufgelöst. Prüfen Sie, ob der Wert funktioniert, wenn Sie auf jenem Server psql -h <host> ausführen.
Certificate verify failed — der Server zeigt ein Zertifikat einer CA, die Ihr System nicht kennt. Hinterlegen Sie das CA-Zertifikat, statt auf Erfordern zu wechseln.
SSH-Schlüssel abgelehnt — prüfen Sie, ob die private Schlüsseldatei zum öffentlichen Schlüssel in authorized_keys passt und ob eine Passphrase eingetragen ist, falls der Schlüssel eine hat.