ssh Tunnel mit JDBC

  • Hallo,


    ich habe meinen Server wie in Infosec empfohlen abgesichert. Dazu habe ich ein Schlüsselpaar mit ssh-keygen erzeugt. Bei der Erstellung der Schlüssel habe ich kein Passwort vergeben. Die Anmeldung über die Mac Konsole mittels ssh bei meinem VServer funktioniert auch über das erzeugte Schlüsselpaar.


    Ich nutze auf meinem Server Firebird 3.0 und möchte mit einem der beiden Mac Toos (RazorSQL oder DBeaver) auf eine FB-Datenbank auf meinem VServer zugreifen. Beide Tools nutzen JDBC für den Zugriff und im Connection Dialog kann ich in beiden Systemen einen ssh Tunnel zum Server konfigurieren. Dazu gebe ich die vhost Adresse und den Port 22 an, meinen User und den privaten Schlüssel. Das ist exakt dieselbe Konfiguration, mit der ich auch über die Shell zugreife. Beide Tools können aber den Tunnel nicht herstellen und melden, der private Schlüssel sei invalid. Ich habe mich einmal durch die log Dateien der beiden Anwendungen gewühlt und dabei ist mir aufgefallen, dass ein Tool im Log File den Eintrag hatte, dass das Passwort Feld leer sei. Das stimmt, weil ich ja bei der Schlüsselgenerierung keines vergeben habe. Hat irgendjemand Erfahrung mit ssh Tunnel über JDBC, welche erklären könnte, warum die Tools meinen, der Schlüssel sei invalid, während derselbe Schlüssel in der Konsole funktioniert?

  • Du hast als Schlüsselformat sicherlich ed25519 gewählt und deine Software nutzt eine uralte Java-Version die das nicht unterstützt. Du könntest als Workaround versuchen den ssh-agent nutzen bzw. stellst in der Software ein das das System SSH verwendet wird (falls die Software das kann).

  • Bensen : Ein Account kann mehrere Public-Keys haben und 1 Benutzer kann auch mehrere Keys haben. ssh probiert durch alle erlaubten Keys, das sieht man bei ssh -v user@host. Zusätzlich gibt es noch die ~/.ssh/config wo man dediziert pro Host verschiedene Optionen wie Ports, Keys, etc definieren kann.

  • vmk Das ist richtig.


    Mein Ansatz ist/war folgender: per Konsole meldest er sich mit Benutzer B1 & Key1 an; über JDBC hat er aber eventuell einen anderen Benutzer und meldet sich hier mit B2 & Key1 an. wodurch JDBC eine invalid Key Meldung ausgibt weil B2 eigentlich nicht den Schlüssel von B1 kennen sollte.

  • vmk Das ist richtig.


    Mein Ansatz ist/war folgender: per Konsole meldest er sich mit Benutzer B1 & Key1 an; über JDBC hat er aber eventuell einen anderen Benutzer und meldet sich hier mit B2 & Key1 an. wodurch JDBC eine invalid Key Meldung ausgibt weil B2 eigentlich nicht den Schlüssel von B1 kennen sollte.

    Bei beiden Programmen kann ich in der SSH Tunnel Konfiguration einen Nutzer angeben. Dort benutze ich B1, genau wie beim Zugriff über ssh in der Konsole.


    Du hast als Schlüsselformat sicherlich ed25519 gewählt und deine Software nutzt eine uralte Java-Version die das nicht unterstützt. Du könntest als Workaround versuchen den ssh-agent nutzen bzw. stellst in der Software ein das das System SSH verwendet wird (falls die Software das kann).

    Ja, ich glaube ich habe ed25519 als Schlüsselformat verwendet. Bei beiden Programmen habe ich die aktuellste Version geladen, die sogar von diesem Jahr ist, so dass wahrscheinlich keine uralt Version von Java verwendet wird. Das mit dem Workaround verstehe ich nicht. Die beiden Programme nutzen ja ssh (als Tunnel zum Server), wie genau soll ich hier einen ssh-Agenten einsetzen?

    Bensen : Ein Account kann mehrere Public-Keys haben und 1 Benutzer kann auch mehrere Keys haben. ssh probiert durch alle erlaubten Keys, das sieht man bei ssh -v user@host. Zusätzlich gibt es noch die ~/.ssh/config wo man dediziert pro Host verschiedene Optionen wie Ports, Keys, etc definieren kann.

    Ich werde dann einmal einen rsa Schlüssel erstellen und den als Zweitschlüssel für den Benutzer B1 verwenden. Diesen werde ich dann mit Passwort verschlüsseln und versuchen diesen bei den Programmen zu nutzen.

  • Habe jetzt einen neuen User angelegt, ein rsa Schlüsselpaar erzeugt und mit Passwort verschlüsselt. Ich kann mich mit dem neuen User und dem neuen rsa Schlüssel über ssh an der Konsole anmelden. DBeaver meldet aber weiterhin invalid private key. In der Log Datei finde ich:


    Was könnte die Ursache sein, dass der Schlüssel als invalid erklärt wird, obwohl ich mich über sie Shell mit ssh und diesem Schlüssel anmelden kann?

  • Die Java-SSH Implementierung JSCH kann kein ed25519, vgl. http://www.jcraft.com/jsch/ und Feature Request: Add support for Ed25519 (2015).


    Das ist aber nicht schlimm, du kannst in DBeaver einfach mit dem System-Client die SSH-Verbindung aufbauen, vgl. https://github.com/dbeaver/dbe…35#issuecomment-364732736 . Da du ja sicherlich den ssh-agent benutzt, geschieht das komplett automatisch im Hintergrund :)

  • DBeaver braucht laut kurzer Recherche einen privaten Schlüssel im RSA-Format. Wie sieht die erste Zeile Deiner Schlüsseldatei aus?

    -----BEGIN OPENSSH PRIVATE KEY-----


    Die nächste Zeile ist bereits verschlüsselt.

    Ich habe aber sicher einen rsa Key erstellt: sudo ssh-keygen -b 4096 -t rsa -f ~/.ssh/<id_vhost_name> steht noch in der History



    Die Java-SSH Implementierung JSCH kann kein ed25519, vgl. http://www.jcraft.com/jsch/ und Feature Request: Add support for Ed25519 (2015).


    Das ist aber nicht schlimm, du kannst in DBeaver einfach mit dem System-Client die SSH-Verbindung aufbauen, vgl. https://github.com/dbeaver/dbe…35#issuecomment-364732736 . Da du ja sicherlich den ssh-agent benutzt, geschieht das komplett automatisch im Hintergrund :)

    Danke, das schaue ich mir mal an.

  • Du machst das Portforwarding manuell, d.h. ssh user@server -L1234:127.0.0.1:3306 und im Biber verbindest du dich dann zu IP 127.0.0.1 und Port 1234.

  • Habe es jetzt gelöst. Danke für Eure Hilfe.


    Habe zuerst einmal das Portforwarding direkt über die Console eingerichtet:


    ssh -L 1234:v123456789xxx.supersrv.de:3050 user@v123456789xxx.supersrv.de


    Dann konnte ich erkennen, dass die Verbindung zustandekommt. Aber der Firebird Server hat keine Verbindung zur Datenbank zugelassen. In der firebird.conf habe ich dann gesehen, dass als Remothost nur localhost zugelassen war und damit eine Verbindung von außen ausgeschlossen war. Das habe ich gändert. Dann war noch die WireCrypt Einstellung auf dem Server und dem Client unterschiedlich. Nachdem ich diese angeglichen habe, hat es dann funktioniert. Dann habe ich die Verbindung wieder in dem Fenster bei DBeaver eingegeben, in dem Shellcommands vor Verbindungsverstellung eingetragen werden.


    Jetzt funktioniert es so, wie gewollt.