[RÉSOLU] Accès Mysql refusé sur poste client

kenny44 · Le 19/12/2024, à 11:01

Bonjour à tous;
Hier, je ne sais pas pourquoi ni comment, mon pc client s'est déconnecté de Mysql en laissant des locks sur des devis/factures Laurux etc...
Depuis, impossible le connecter à la base, que ce soit avec les identifiants habituels, ou avec des nouveaux id avec les droits nécessaires.
Mon serveur écoute bien sur 0.0.0.0, mes id sont en '%'
La ou cela se complique, c'est que je peux, avec le client, me connecter sur mon ancienne base sur un ancien OS dans le même PC (HDD séparés). Ce qui indique que le souci vient bien de mon PC serveur, sinon le client ne se connecterait pas.

Je suis assez perdu. Si quelqu'un peut regarder avec moi ce qui se passe dans les paramètres de mon serveur, ce serait bien.

L'installation :
Un PC serveur avec Mysql/Laurux pour ma compta (PC fixe sur réseau)
Un ordi portable qui se connecte sur site actuellement (à terme, l'idéal serait de pouvoir se connecter depuis l'extérieur du site égallement, mais je ne sait pas comment faire actuellement)

Merci d'avance pour votre aide

Dernière modification par kenny44 (Le 24/12/2024, à 15:14)

kenny44 · Le 19/12/2024, à 12:17

Bonjour kastopidiak,
oups, je n'avais pas vu cette rubrique. Je ne sais pas si je peux déplacer le sujet...

Voici le retour de ta commande :

crealicia@crealicia-ms7a57:~$ systemctl -l --no-pager status mysql
● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2024-12-19 09:02:01 CET; 2h 14min ago
    Process: 5667 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
   Main PID: 5675 (mysqld)
     Status: "Server is operational"
      Tasks: 40 (limit: 18929)
     Memory: 462.4M
        CPU: 1min 1.929s
     CGroup: /system.slice/mysql.service
             └─5675 /usr/sbin/mysqld

déc. 19 09:02:00 crealicia-ms7a57 systemd[1]: Starting MySQL Community Server...
déc. 19 09:02:01 crealicia-ms7a57 systemd[1]: Started MySQL Community Server.

xubu1957 · Le 19/12/2024, à 12:39

Bonjour,

J'ai demandé à notre Modération, le déplacement de la discussion dans la section Serveurs.

kenny44 · Le 19/12/2024, à 12:42

OK, merci.

Maintenant, plus qu'a solutionner mon problème, j'espère que quelqu'un trouvera, vu que le serveur tourne...

kenny44 · Le 19/12/2024, à 15:34

Salut kastopidiak,

non effectivement :

crealicia@crealicia-ms7a57:~$ mysql -u franck@% -p
Enter password: 
ERROR 1045 (28000): Access denied for user 'franck@%'@'localhost' (using password: YES)
crealicia@crealicia-ms7a57:~$ mysql -u franck -p -h 192.168.1.17
Enter password: 
ERROR 1045 (28000): Access denied for user 'franck'@'crealicia-ms7a57.home' (using password: YES)

Pourtant, en passant par la boite de connexion Laurux, j'arrive à me connecter. Pourquoi ?

Dernière modification par kenny44 (Le 19/12/2024, à 15:57)

kenny44 · Le 19/12/2024, à 19:21

Alors, je vais détailler :
-> Je lance bien les commandes sur le serveur, et la connexion est refusée
-> La connexion root passe bien, tout comme les autres identifiants
-> Laurux, en fait bascule sur l'autre identifiant, et fonctionne sous mysql, ma base de donnée est en fait tous ses fichiers, devis etc, et peut fonctionner en multipostes (ERP gestion entreprise). Dans la boite de connexion, j'identifie ma base, l'ip du serveur, l'identifiant et le MDP Mysql.

kenny44 · Le 19/12/2024, à 20:45

Voici le retour de la commande demandée :

crealicia@crealicia-ms7a57:~$ sudo mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 23
Server version: 8.0.40-0ubuntu0.22.04.1 (Ubuntu)

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select user,host from mysql.user;
+------------------+-----------+
| user             | host      |
+------------------+-----------+
| Franck           | %         |
| alicia           | %         |
| fker             | %         |
| franck           | %         |
| crealicia        | localhost |
| debian-sys-maint | localhost |
| mysql.infoschema | localhost |
| mysql.session    | localhost |
| mysql.sys        | localhost |
| phpmyadmin       | localhost |
| root             | localhost |
+------------------+-----------+
11 rows in set (0,00 sec)

A savoir :
Le login crealici@localhost est celui qui est sur le serveur. L'identifiant Franck est celui qui était sur le pc client. Les autres (franck , alicia et fker) sont des identifiants qui ont été mis en place pour essai, ou pour utilisation ultérieure -> alicia).
l

kenny44 · Le 20/12/2024, à 09:27

Bonjour kastopidiak,

Donc depuis le serveur c'est ok :

crealicia@crealicia-ms7a57:~$ mysql -u Franck -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.40-0ubuntu0.22.04.1 (Ubuntu)

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> exit;

Par contre depuis le client :

ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.17:3306' (113)

Un problème de port d'écoute ?

iznobe · Le 20/12/2024, à 10:50

Bonjour , sur le serveur , donne le retour de :

ip a

kenny44 · Le 20/12/2024, à 11:03

Bonjour iznobe,
Voici le retour de ta commande :

crealicia@crealicia-ms7a57:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 4c:cc:6a:bb:af:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.17/24 brd 192.168.1.255 scope global dynamic noprefixroute enp3s0
       valid_lft 76377sec preferred_lft 76377sec
    inet6 2a01:cb05:8d27:e300:fb80:5d27:87e2:8bb/64 scope global temporary dynamic 
       valid_lft 86384sec preferred_lft 584sec
    inet6 2a01:cb05:8d27:e300:d70e:1c53:2df2:6bbf/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86384sec preferred_lft 584sec
    inet6 fe80::d1:5a44:d54b:1f44/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

iznobe · Le 20/12/2024, à 11:22

sur le client :

ip a

ping -c2 192.168.1.1

ping -c2 192.168.1.17

kenny44 · Le 20/12/2024, à 11:57

OK, pour l'IP, j'était sûr que c'était la bonne.
Voici le retour de la commande :

sudo ss -tnlp sport = :3306
State          Recv-Q         Send-Q                 Local Address:Port                   Peer Address:Port         Process         
LISTEN         0              151                                *:3306                              *:*             users:(("mysqld",pid=1296,fd=23))

kenny44 · Le 20/12/2024, à 12:52

Oups, je n'avais pas vu son message. Voici le retour des 3 commandes sur le client :

franck@franck-SPC-N:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host noprefixroute  
      valid_lft forever preferred_lft forever
2: wlo2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
   link/ether c8:cb:9e:5a:df:0c brd ff:ff:ff:ff:ff:ff
   altname wlp0s12f0
   inet 192.168.1.19/24 brd 192.168.1.255 scope global dynamic noprefixroute wlo2
      valid_lft 86388sec preferred_lft 86388sec
   inet6 2a01:cb05:8d27:e300:7c19:bd99:8af0:cb6a/64 scope global temporary dynamic  
      valid_lft 86399sec preferred_lft 599sec
   inet6 2a01:cb05:8d27:e300:158f:3d9c:7f04:8ff1/64 scope global dynamic mngtmpaddr noprefixroute  
      valid_lft 86399sec preferred_lft 599sec
   inet6 fe80::eb63:7d4a:2371:ba3e/64 scope link noprefixroute  
      valid_lft forever preferred_lft forever
franck@franck-SPC-N:~$ ping -c2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=9.82 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=13.7 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 9.824/11.762/13.700/1.938 ms
franck@franck-SPC-N:~$ ping -c2 192.168.1.17
PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=100 ms
64 bytes from 192.168.1.17: icmp_seq=2 ttl=64 time=4.67 ms

--- 192.168.1.17 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 4.665/52.416/100.168/47.751 ms

et la commande suivante (faite sur le serveur):

crealicia@crealicia-ms7a57:~$ sudo grep -r bind-address /etc/mysql/
/etc/mysql/mysql.conf.d/mysqld.cnf:# bind-address = 0.0.0.0
/etc/mysql/mysql.conf.d/mysqld.cnf:# mysqlx-bind-address = 0.0.0.0

iznobe · Le 20/12/2024, à 13:02

Vu que l' acces à l' air OK , il faudrait verifier le parefeu du serveur ou les IPTABLES selon la config .

kenny44 · Le 20/12/2024, à 13:13

Normalement, j'ai tout désactivé lorsque l'accès s'est bloqué. Je n'ai pas de gestionnaire de pare-feu. Là je sèche complètement.
Après, si j'installe iptables, ça prends la main sur ce qui est actuel, ou cela s'ajoute ? Car ne sachant pas ce qui bloque, je vais tatonner...

kenny44 · Le 20/12/2024, à 13:19

Voici les retours de UFW et iptables :

UFW :

Vers                       Action      De
----                       ------      --
22/tcp                     ALLOW IN    Anywhere                  
3306                       ALLOW IN    192.168.1.1               
3306                       ALLOW IN    0.0.0.0                   
22/tcp (v6)                ALLOW IN    Anywhere (v6)

IPTABLES :

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

c'est les deux commandes qui fonctionnent.

iznobe · Le 20/12/2024, à 13:21

n' installe rien de plus qui pourrait interferer .
de toute façon , il me semble que iptables ou ses cousins sont installés par defaut sur toute les distrib ubuntu .

Si tu ne sais pas , c' est que tu n' y as rien modifié et c' est une bonne chose .

Le plantage a du perturbé des fichiers .
il faudrait ( je sais pas si tu peux ) , demonter les partitions EXT4 sur le serveur pour faire un controle avec une session live et passer les les commandes suivantes :

lsblk -fe7 | grep ext

puis :
fsck -fyv /dev/REFERENCE_BLOC
en remplacant " REFERENCE_BLOC "
par sda1 sda2 etc ...
ou nvme0n1p1 nvme0n1p2 etc , en fonction de la liste que tu obtiendras avec la 1ere commande .

d ' ailleurs , donne maintenant le retour de :

lsblk -fe7 | grep ext

, ca sera plus simple .

PS , tu devrais supprimer cette ligne de ton UFW :

3306                       ALLOW IN    192.168.1.1

puisque la suivante autorise toutes les IP .

Dernière modification par iznobe (Le 20/12/2024, à 13:23)

kenny44 · Le 20/12/2024, à 13:32

Voici le retour demandé (pas celui en live :

crealicia@crealicia-ms7a57:~$ lsblk -fe7 | grep ext
└─sda1 ext4   1.0              78403dfe-f672-4099-b3ec-453a685f0000   69,8G    35% /var/snap/firefox/common/host-hunspell
└─sdb2 ext4   1.0              a2162e1a-34fb-48ae-91f0-40649142cdc5   43,6G    55% /media/crealicia/a2162e1a-34fb-48ae-91f0-40649142cdc5
└─sdc1 ext4   1.0   newhome    3d18ed97-fc07-4008-b3aa-6284d4df0d6f  831,1G     4% /home

La ligne a supprimer, ce n'est pas celle qui permet a mon pec client de pouvoir venir sur le port 3306 hors site ?

kenny44 · Le 20/12/2024, à 13:53

J'ai désactiver UFW, mais je ne trouve aucune commande pour iptables.

kenny44 · Le 20/12/2024, à 14:06

Le poste client n'accède toujours pas. Même erreur
Voici la liste des règles :

crealicia@crealicia-ms7a57:~$ sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 5250 packets, 1828K bytes)
 pkts bytes target     prot opt in     out     source               destination         
11956 3446K ufw-before-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
11956 3446K ufw-before-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 6499 1916K ufw-after-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 5395 1833K ufw-after-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 5395 1833K ufw-reject-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 5395 1833K ufw-track-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ufw-before-logging-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-before-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-after-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-after-logging-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-reject-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-track-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 5053 packets, 866K bytes)
 pkts bytes target     prot opt in     out     source               destination         
11312 2019K ufw-before-logging-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
11312 2019K ufw-before-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 6959 1017K ufw-after-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 6959 1017K ufw-after-logging-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 6959 1017K ufw-reject-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 6959 1017K ufw-track-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-after-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-after-input (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-after-logging-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-after-logging-input (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-after-logging-output (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-after-output (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-before-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-before-input (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-before-logging-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-before-logging-input (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-before-logging-output (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-before-output (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-reject-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-reject-input (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-reject-output (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-track-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-track-input (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain ufw-track-output (1 references)
 pkts bytes target     prot opt in     out     source               destination

Dernière modification par kenny44 (Le 20/12/2024, à 14:07)

kenny44 · Le 20/12/2024, à 14:18

Oui, je te confirme que le client à bien une erreur 113.
La commande tennet donne:

telnet: Unable to connect to remote host: Aucun chemin d'accès pour atteindre l'hôte cible

Si je réinstalle MySQL sur le serveur (après sauvegarde de ma base), le problème risque de persister, non ?
Serait-ce possible que ce soit ma box Orange qui bloque même en réseau interne ?

kenny44 · Le 20/12/2024, à 17:13

Voici le retour sur le client :

franck@franck-SPC-N:~$ sudo iptables -L -v -n
[sudo] Mot de passe de franck :  
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination          

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination          

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

iznobe · Le 20/12/2024, à 17:22

pas de parefeu sur le client , genre UFW ?

iptables c ' est la sous-couche ( comme le primaire en peinture ) .
il eput etre sur accept partout , mais un parefeu peut avoir d' autres regles qui bloquent .

Dernière modification par iznobe (Le 20/12/2024, à 17:22)

kenny44 · Le 20/12/2024, à 17:42

Non, il n'y a que le serveur qui a eu UFW, le client n'a rien. Et comme les deux pc pouvant être client sont refusés par le serveur, alors qu'ils peuvent accéder à l'ancien serveur sans problème, c'est le serveur actuel qui bloque.
Tout a été redémarré.
Il n'y aurait pas un moyen pour réinitialiser et retirer toutes les consignes "pare feu" sur le serveur ?

Dernière modification par kenny44 (Le 20/12/2024, à 17:43)

kenny44 · Le 20/12/2024, à 18:04

Commandes faites, voici le résultat iptables :

crealicia@crealicia-ms7a57:~$ sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

accès toujours refusé... Je n'y comprends rien...

Dernière modification par kenny44 (Le 20/12/2024, à 18:06)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 19/12/2024, à 11:01

[RÉSOLU] Accès Mysql refusé sur poste client

#2 Le 19/12/2024, à 12:17

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#3 Le 19/12/2024, à 12:39

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#4 Le 19/12/2024, à 12:42

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#5 Le 19/12/2024, à 15:34

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#6 Le 19/12/2024, à 19:21

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#7 Le 19/12/2024, à 20:45

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#8 Le 20/12/2024, à 09:27

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#9 Le 20/12/2024, à 10:50

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#10 Le 20/12/2024, à 11:03

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#11 Le 20/12/2024, à 11:22

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#12 Le 20/12/2024, à 11:57

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#13 Le 20/12/2024, à 12:52

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#14 Le 20/12/2024, à 13:02

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#15 Le 20/12/2024, à 13:13

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#16 Le 20/12/2024, à 13:19

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#17 Le 20/12/2024, à 13:21

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#18 Le 20/12/2024, à 13:32

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#19 Le 20/12/2024, à 13:53

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#20 Le 20/12/2024, à 14:06

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#21 Le 20/12/2024, à 14:18

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#22 Le 20/12/2024, à 17:13

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#23 Le 20/12/2024, à 17:22

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#24 Le 20/12/2024, à 17:42

Re : [RÉSOLU] Accès Mysql refusé sur poste client

#25 Le 20/12/2024, à 18:04

Re : [RÉSOLU] Accès Mysql refusé sur poste client

Pied de page des forums