Windows logging für SSH-Verbindungen?

[TS]

Hello,

ich frage nochmal nach, ob mir jemand weiterhelfen kann in dieser Sache :-)

Gibt es in Win7-Pro ein Log, in dem ich Fehlermeldungen zu SSH-Verbindungen finden kann? Ich bekomme unter Win7-Pro mit meinem HeidiSQL (64-Bit-Version) keine Verbindung zur Datenbank. Mit dem gleichen HeidiSQL (32-Bit-Version) auf dem alten WinXP-Pro funktioniert es nach wie vor, trotz des Updates auf den neuesten Build.

Nun suche ich Logs, die mir vielleicht weiterhelfen können. Vielleicht muss man die auch extra einschalten?

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Gibt es in Win7-Pro ein Log, in dem ich Fehlermeldungen zu SSH-Verbindungen finden kann?

Windows 7 kennt kein SSH. Das ist eine Netzwerkverbindung wie irgendeine beliebige andere unbekannte TCP-Verbindung.

Nun suche ich Logs, die mir vielleicht weiterhelfen können. Vielleicht muss man die auch extra einschalten?

Das Log vom Server. Prüfungen mit anderen Clients, ob die grundsätzlich eine SSH-Verbindung zum Server aufbauen können, wäre auch eine Testmaßnahme.

dedlfix.

[TS]

Hello,

Gibt es in Win7-Pro ein Log, in dem ich Fehlermeldungen zu SSH-Verbindungen finden kann?

Windows 7 kennt kein SSH. Das ist eine Netzwerkverbindung wie irgendeine beliebige andere unbekannte TCP-Verbindung.

Nun suche ich Logs, die mir vielleicht weiterhelfen können. Vielleicht muss man die auch extra einschalten?

Das Log vom Server. Prüfungen mit anderen Clients, ob die grundsätzlich eine SSH-Verbindung zum Server aufbauen können, wäre auch eine Testmaßnahme.

Soweit ich sehen kann, kommt auf dem Server überhaupt kein Request an. Zumindest sind weder im AUTH-Log, noch im DB-Err-Log irgendwelche Fehlermeldungen dazu. Das Err-Log der DB habe ich seinerzeit extra eingerichtet, um Fail2Ban einen Ansatzpunkt zu geben und es arbeitet auch einwandfrei.

Gibt es in Win7-Pro ein Log, in dem ich Fehlermeldungen zu SSH-Verbindungen finden kann?

Windows 7 kennt kein SSH. Das ist eine Netzwerkverbindung wie irgendeine beliebige andere unbekannte TCP-Verbindung.

Welche Logs könnten denn sonst eventuell zu Rate gezogen werden?

Nun suche ich Logs, die mir vielleicht weiterhelfen können. Vielleicht muss man die auch extra einschalten?

Das Log vom Server. Prüfungen mit anderen Clients, ob die grundsätzlich eine SSH-Verbindung zum Server aufbauen können, wäre auch eine Testmaßnahme.

Putty arbeitet mit Key. Filezilla arbeitet über Port 22 mit Key. Alles fein also.
Nur HeidiSQL 64Bit will nicht mehr.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Gibt es in Win7-Pro ein Log, in dem ich Fehlermeldungen zu SSH-Verbindungen finden kann?

Windows 7 kennt kein SSH. Das ist eine Netzwerkverbindung wie irgendeine beliebige andere unbekannte TCP-Verbindung.

Welche Logs könnten denn sonst eventuell zu Rate gezogen werden?

Ich wüsste nicht, dass Netzwerkverbindungen geloggt werden, also außerhalb dessen, was mit netstat anschaubar ist. Aber das ist ja kein Logging in dem Sinne, sondern nur eine Momentaufnahme.

dedlfix.

[Reto]

☝️ https://youtu.be/nn2FB1P_Mn8

Nein, Spaß beiseite. Heidi liebt auch gerne mal eine Neuinstallation.

[TS]

Hello,

☝️ https://youtu.be/nn2FB1P_Mn8

Nein, Spaß beiseite. Heidi liebt auch gerne mal eine Neuinstallation.

Hatte ich bisher noch nie Probleme.
Aber dafür habe ich zum Fehler noch etwas gefunden:

• https://www.nsoftware.com/kb/xml/06101501.rst
• https://www.percona.com/blog/2012/11/08/debugging-mysql-ssl-problems/

Mal sehen, ob ich damit weiterkomme. Zunächst werde ich wohl mal eine neue Schlüsselgruppe mit längerer Sequenz erstellen. Kann sein, dass mein Key noch so ein zu kurzer, wie beschrieben steht, ist.

Liebe Grüße
Tom S.

[derdicki]

Hallihallo!

Soweit ich sehen kann, kommt auf dem Server überhaupt kein Request an. Zumindest sind weder im AUTH-Log, noch im DB-Err-Log irgendwelche Fehlermeldungen dazu. Das Err-Log der DB habe ich seinerzeit extra eingerichtet, um Fail2Ban einen Ansatzpunkt zu geben und es arbeitet auch einwandfrei.

Putty arbeitet mit Key. Filezilla arbeitet über Port 22 mit Key. Alles fein also.
Nur HeidiSQL 64Bit will nicht mehr.

Ich frage eher der Vollständigkeit halber, aber manchmal vergisst man das ja wirklich: Hast Du vielleicht noch die Windows- Firewall aktiv, und für die neue Installation noch keine Erlaubnis gegeben?

Beste Grüsse, Tobias Hahner

[TS]

Hello,

Ich frage eher der Vollständigkeit halber, aber manchmal vergisst man das ja wirklich: Hast Du vielleicht noch die Windows- Firewall aktiv, und für die neue Installation noch keine Erlaubnis gegeben?

Die Frage ist berechtigt. Ich denke aber, dass Zugriffe erlaubt sein sollten. Meldungen der FW kommen keine mehr. Ich prüfe es jetzt aber noch einmal, bestimmt zum 10ten.

Liebe Grüße
Tom S.

[Regina Schaukrug]

Vermutlich fehlt Dir irgendeine DLL. Vielleicht willst Du es erst mal mit gut getesteter Standardsoftware versuchen:

• MySQL Client für Windows (Server nicht installieren!)
• MariaDB Client für Windows (Server nicht installieren!)
• MySQL-Workbench für Windows
• Mysql-"Shell" für Windows

[TS]

Hello,

Vermutlich fehlt Dir irgendeine DLL. Vielleicht willst Du es erst mal mit gut getesteter Standardsoftware versuchen:

• MariaDB Client für Windows (Server nicht installieren!)

Hat den gleichen Fehler verursacht, aber zusätzlich eine etwas aussagefähigere Fehlermeldung geliefert: "dh key too short" -> (Diffie Hellman Key zu kurz).

Das hat mich dann nach weiteren drei Stunden Lesen auf eine Lösung gebracht:

In der my.cnf ergänzen:
ssl-cipher = ssl-cipher = AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA

Cipher im Feld für die Verschlüsselungsart angeben

Nun ist das Problem mit den SQL-Clients auch gelöst.

Liebe Grüße
Tom S.

[Regina Schaukrug]

Das hat mich dann nach weiteren drei Stunden Lesen auf eine Lösung gebracht:

In der my.cnf ergänzen:
ssl-cipher = AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA

Ich glaube, es entsteht hierdurch dieses Problem.

Das wäre also "nicht wirklich" eine Lösung, denn damit setzt Du die Verschlüsselung auf ein Niveau herunter, die nicht "dem Stand der Technik" entspricht. Richtig wäre es gewesen, dem Server ein Update zu verpassen, damit der aktuelle Schlüssellängen verarbeitet - oder, alternativ, die Verbindung zum Datenbankserver generell via VPN oder SSH (aber mit aktuellen Versionen) zu tunneln. Wobei das Serverupdate zu preferieren ist, weil ja sicherlich nicht nur die Verschlüsselung ein Update erfahren hat, sondern auch Bugs oder Performanceprobleme behoben wurden. Auf alte XP-Clients muss man ja schon seit ein paar Jahren keine Rücksicht mehr nehmen.

[TS]

Hello,

Ich glaube, es entsteht hierdurch dieses Problem.

Möglich und nicht schön.

Ich habe noch Version 5.5.41-0+wheezy1 laufen und bekomme auch z. Zt keine neuere installiert. Dazu müsste ich die Vorgabe brechen, nur mit Apt-Tools zu arbeiten.

Welches ist den die höchste frei verfügbare Version?
Ich müsste wohl ohnehin auf Maria-DB umsteigen?

Liebe Grüße
Tom S.

[Regina Schaukrug]

Ich habe noch Version 5.5.41-0+wheezy1 laufen und bekomme auch z. Zt keine neuere installiert. Dazu müsste ich die Vorgabe brechen, nur mit Apt-Tools zu arbeiten.

Nein. Das Repo von Mysql einzubinden läuft (wohl) unter "nur mit Apt-Tools zu arbeiten". deb gehört irgendwie auch dazu, weil apt ja deb benutzt und visa versa.

Achte bitte UNBEDINGT hierauf und ziehe das zunächst mit einem Testsystem durch.

[TS]

Hello,

was mir dabei durch den Kopf geht:
ohne diesen Eintrag in der my.cnf hat mein gutes altes WinXP mit dem Server korrespondieren können. Erst Win/ hat gezickt.

Nachdem ich das Downgrading im Server und in der Heidi bzw. dem SQLyog auf Win7 eingetrgen hatte, ging es damit auch. Dann muss das Schlüssellängendefizit doch in Win7 liegen, oder?

Liebe Grüße
Tom S.

[Regina Schaukrug]

Dann muss das Schlüssellängendefizit doch in Win7 liegen, oder?

Nein. Auf dem Server entfaltet das womöglich keine Wirkung, der macht möglicherweise das selbe wie vorher. Nur die Clients nicht: Seit dem Jahr 2015 wird wie folgt empfohlen:

Zitat:

Als Schutzmaßnahme sollten Server die Unterstützung für exporttaugliche Cipher Suites abschalten und mindestens 2048 Bit lange Gruppen verwenden. Clients sollten Gruppen verwerfen, die kürzer als 1024 Bit sind.

Windows XP macht das noch nicht (und es wurde wegen des Zeitablaufs (wohl) auch nicht mehr implementiert) Win 7 dürfte also also bei DH "Gruppen verwerfen, die kürzer als 1024 Bit sind". Ich denke mal, dass sind letztendlich auch API-Calls, dass MySQL (der Client und der Server) hier also die API des OS oder libs wie OpenSSL nutzt. Durch Deinen Eintrag gestattest Du (wohl) den moderneren Clients die Nutzung von "Gruppen, die kleiner als 1024 Bit" sind.

Das hier sollte genug Anlass sein, ein Upgrade durchzuführen (Quelle wie oben):

Der Logjam-Angriff kann in der Praxis performant durchgeführt werden, da ein Großteil der Rechenarbeit zum Brechen des Schlüssels schon vor dem Verbindungsaufbau durchgeführt werden kann. Der erforderliche Rechenaufwand während des eigentlichen Schlüsselaustauschs dauert etwa 70 Sekunden

…

Dann muss das Schlüssellängendefizit doch in Win7 liegen, oder?

Einfache Grundregel für SSL/TLS-Probleme: Wenn neue Clients mit alten Servern nicht können, dann liegt es meist nicht am Client... sondern eben daran, dass die alten Server etwas nicht können, was die neuen Clients aus Gründen der Sicherheit fordern.

[TS]

Hello,

Dann muss das Schlüssellängendefizit doch in Win7 liegen, oder?

Einfache Grundregel für SSL/TLS-Probleme: Wenn neue Clients mit alten Servern nicht können, dann liegt es meist nicht am Client... sondern eben daran, dass die alten Server etwas nicht können, was die neuen Clients aus Gründen der Sicherheit fordern.

Ergo:
die Server-Hosts müssen dringend ein Upgrade erhalten. Käme mir auch wegen der Apache-Versionen (2.2 -> 2.4) und PHP7 entgegen. Dann gibt es aber vermutlich nur noch Maria-DB? Hat die Maria denn wichtige Unterschiede zur MySQL 5.5.41-0+wheezy1? Muss da in den Applikationen viel geändert werden?

Wird auf jeden Fall ein mächtiger Aufriss, den die "Kunden" bestimmt vermeiden wollen. Und mit meinem eigenen Host kann ich nicht einfach ausscheren; der muss genauso laufen, wie die anderen drei.

Liebe Grüße
Tom S.

[Regina Schaukrug]

Ergo: die Server-Hosts müssen dringend ein Upgrade erhalten. Käme mir auch wegen der Apache-Versionen (2.2 -> 2.4) und PHP7 entgegen. Dann gibt es aber vermutlich nur noch Maria-DB?

Du kannst, wenn du partout willst, das mySQL Repo zu jeder noch (von Debian!) unterstützten Debian-Version hinzufügen.

Hat die Maria denn wichtige Unterschiede zur MySQL 5.5.41-0+wheezy1?

Äh. Was ist "wichtig"? Das es sicherer ist, größere Datenmengen verarbeiten kann, dass es weitere neue Datenbank- und Datentypen für diverse Anwendungsmöglichkeiten gibt? Das viele MariaDB eine bessere und stabilere Unterstützung der Community und Nutzer zutrauen als dem jetzt von Oracle - die ja ein kostenpflichtiges Konkurrenzprodukt haben - gepflegtem MySQL? Die Release-Notes stehen hier, 3. Spalte rechts oben

Muss da in den Applikationen viel geändert werden?

Das kommt drauf an. Ich vermute aber mal: Eher nicht "ziemlich unwahrscheinlich". Geändert hat sich vor allem die Leistungsfähigkeit und es ist verdammt viel neues Zeug hinzugekommen. Du kannst also vieles besser machen - oder eben genau so wie bisher.

Bitte beachte, dass sich nach einer Neueinstallation von mariaDB der Root des Linux-Servers auf der Datenbank ohne Passwort anmelden kann.

Also:

~> su #(oder : sudo su)
Passwort: 
# mysql [-u root ][-p localhost]
mysql > 

Das ist also etwas anders, als Du es noch gewohnt bist. Aber die mögliche Behauptung, dass derlei unsicher wäre, hat aus meiner Sicht keine stützenden Argumente. Der root käme auch so an die Daten. Er muss nur wollen und, naja, können.

Die Nutzerverwaltung hat sich recht grundlegend geändert. Ich würde die Datenbanken einzeln exportieren und die Nutzer, wenn es denn wenige sind, komplett neu anlegen.

Die Hashes der Passwörter sind jetzt z.B. in der DB.Tabelle.Spalte mysql.user.authentication_string.

[Regina Schaukrug]

Die Hashes der Passwörter sind jetzt z.B. in der DB.Tabelle.Spalte mysql.user.authentication_string.

Von der früher mal propagierten asbach-Methode die Passwörter mit

update mysql.user set password=password("Geheim"); 
flush tables;

zu ändern würde ich also die Finger lassen.

grant WELCHE on `datenbank`.`*` identified by "Geheim";

ist jetzt quasi Pflicht.