Hallo zusammen
Vorab: Es geht nicht um MySQL, sondern um MariaDB. Debian 9 verwendet halt aus Kompatibilitätsgründen immer noch Pfade, Variablen etc., welche das Wort mysql enthalten…
Wie haben einen MariaDB Master/Master-Cluster inkl einem Skript welches Stamm-, Client-, sowie Serverzertifikate generiert. Die Clientzertifikate werden vom Skript jeweils auf den anderen Server verteilt.
Nun:
Wenn ich in der /etc/mysql/mariadb.conf.d/50-server.cnf den Server-Part angebe, dann passiert soweit nix, es scheint optional zu sein ob der Client nun Zertifikate verwendet oder nicht.
Wenn ich aber sowas angebe, die Konfig der Client-Zertis, dann meckers das mysql-Konsolentool bei einer Eingabe von mysql -h localhost -u root -p password plötzlich:
# J.M., 2020-01-17 {
[client-mariadb]
#ssl = 0
#ssl-cert = /etc/mysql/client-cert.pem
#ssl-key = /etc/mysql/client-key.pem
#ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
#ssl = 0
#ssl-cert = /etc/mysql/client-cert.pem
#ssl-key = /etc/mysql/client-key.pem
#ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
Sicherheitshalber habe ich 2 Abschnitte gemacht, und aktuell ist auch wieder jeder Zeile auskommentiert damit’s wieder geht.
Frage: Was muss ich da machen?
Ich möchte EINZING UND ALLEINE dass die Benutzer replication_server_1 sowie replication_server_2 die X509-Technik verwenden… alle anderen sind eh an localhost gebunden und somit nicht öffentlich.
Aber auch replication_server_1 sowie replication_server_2 sind nicht wirklich öffentlich replication_server_1 akzeptiert nur die IP von Server 2, replication_server_2 nur die von Server 1!
Um die replication_server_X-Benutzer zu erstellen, verwende ich folgende Befehl:
FLUSH PRIVILEGES;
DROP USER IF EXISTS 'replication_server_1'@'1.1.1.1';
FLUSH PRIVILEGES;
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication_server_1'@'1.1.1.1' IDENTIFIED BY 'my_password' REQUIRE X509;
UPDATE mysql.user SET authentication_string = PASSWORD('my_password') WHERE User = 'replication_server_1';
FLUSH PRIVILEGES;
resp.
FLUSH PRIVILEGES;
DROP USER IF EXISTS 'replication_server_2'@'2.2.2.2';
FLUSH PRIVILEGES;
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication_server_2'@'2.2.2.2' IDENTIFIED BY 'my_password' REQUIRE X509;
UPDATE mysql.user SET authentication_string = PASSWORD('my_password') WHERE User = 'replication_server_2';
FLUSH PRIVILEGES;
(CREATE USER scheint Mariadb 10.x nicht zu unterstützen, deshalb GRANT; und das nachträgliche UPDATE ist aus Kompatibilitätsgründen besser habe ich festgestellt. Und ein paar mal FLUSH PRIVILEGES schadet sicher auch nicht.)
Nun: Warum zum Teufel kann ich mich dann plötzlich lokal nicht mehr als root per mysql -h localhost -u root -p my_password einloggen mit diese Konfig, WTF!!
Der root-Benutzer ist schliesslich NICHT mit „REQUIRE X509“ geflaggt!!!
# J.M., 2020-01-17 {
[client-mariadb]
ssl = 1
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
ssl = 1
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
oder auch
# J.M., 2020-01-17 {
[client-mariadb]
ssl = 0
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
ssl = 0
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
(Habe zuerst gedacht ssl = x bestimmt ob das Zeugs in jedem Fall ZWANGSLÄUFIG angewendet werden soll - also für jeden Account)
Wie kriege ich es also hin dass die Verschlüsselung nur für einen bestimmten Benutzer mysql_replication_X erforderlich wird.
Und komisch ist, dass das mysql-Konsolentool stress macht mit der Meldung „Unable to very peer checksum“, das Windows-MySQL-GUI-Frontend-Tool „HeidiSQL“ wiederum nicht. WTF hoch 27!!!
Haben die Client-SSL-Einträge in der Konfig zu folge, dass auf dem lokalen System dann mit dem mysql-Konsolentool immer versucht wird die Client-Zertifikate (zur Verbindungsverschlüselung) zu verwenden - auch wenn dann der root halt gar nicht mit „… REQUIRE X509“ geflaggt ist und das zum ganzen Stress führt.
Dann müsste ich evtl. auf diese Client-Einträge verzichten, um bei der SQL-Anweisung wo der Master-Server definiert wird irgendeinen Pfad mitliefern?
Z.B. was in der Art (Pseudocode):
STOP SLAVE;
RESET SLAVE;
RESET MASTER;
CHANGE MASTER TO master_host='1.1.1.1', master_port=3306, master_user='replication_server_1', master_password='my_password', master_log_file='mysql-bin.000001', master_log_pos=313, ssl-cert='/etc/mysql/client-cert.pem' ssl-key='/etc/mysql/client-key.pem' ssl-ca='/etc/mysql/ca-cert.pem'
START SLAVE;
FLUSH PRIVILEGES;
EXIT;
...und dann noch in der Konsole `systemctl restart mysql` ??
Eben halb diesen ganzen Kran nur für diese einzelne Verbindung:
" ssl-cert=’/etc/mysql/client-cert.pem’ ssl-key=’/etc/mysql/client-key.pem’ ssl-ca=’/etc/mysql/ca-cert.pem’ "
Danke für die Feedbacks.
Grüsse, Jan