Il server risponde con un pacchetto vuoto durante la negoziazione della sessione, causando un errore di pacchetto non valido nel client

14

Sto tentando di connettermi a un server mysql remoto. Questo accade il 100% delle volte.

client: mysql Ver 14.14 Distrib 5.7.12, per
server Win32 (AMD64) : 5.0.95

Questo è l'errore che ottengo:

C:\>mysql -h example.com -P 3306 -D prod_rcadb -u username -p
Enter password: **********
ERROR 2027 (HY000): Malformed packet

stesso errore con mysqladmin:

C:\>mysqladmin -h example.com -P 3306 -u username -p version
Enter password: **********
mysqladmin: connect to server at '10.106.24.79' failed
error: 'Malformed packet'

Quindi ho preso un tappo, solo per farmi un'idea di come fosse quella conversazione.

Stretta di mano TCP:

1              2016-04-14 11:18:48.910690         0.000000              137.69.150.80                     10.106.24.79       TCP        66                51157→3306 [SYN] Seq=0 Win=8192 Len=0 MSS=1428 WS=256 SACK_PERM=1   8192
2              2016-04-14 11:18:49.019893         0.109203              10.106.24.79                       137.69.150.80     TCP        66                3306→51157 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=256           5840
3              2016-04-14 11:18:49.019893         0.000000              137.69.150.80                     10.106.24.79       TCP        54                51157→3306 [ACK] Seq=1 Ack=1 Win=65536 Len=0          256

Negoziazione della connessione Mysql:

4              2016-04-14 11:18:49.144696         0.124803              10.106.24.79                       137.69.150.80     MySQL  110        Server Greeting proto=10 version=5.0.95            23
5              2016-04-14 11:18:49.144696         0.000000              137.69.150.80                     10.106.24.79       MySQL  119         Login Request user=bigdata   256<br>
6              2016-04-14 11:18:49.144696         0.000000              10.106.24.79                       137.69.150.80     TCP        60                3306→51157 [ACK] Seq=57 Ack=66 Win=5888 Len=0        23
7              2016-04-14 11:18:49.316301         0.171605              10.106.24.79                       137.69.150.80     MySQL  60           Response                23

Quindi il client si connette a livello TCP, il server ci accoglie con opzioni e stato supportati:

Server Capabilities: 0xa22c
.... .... .... ...0 = Long Password: Not set
.... .... .... ..0. = Found Rows: Not set
.... .... .... .1.. = Long Column Flags: Set
.... .... .... 1... = Connect With Database: Set
.... .... ...0 .... = Don't Allow database.table.column: Not set
.... .... ..1. .... = Can use compression protocol: Set
.... .... .0.. .... = ODBC Client: Not set
.... .... 0... .... = Can Use LOAD DATA LOCAL: Not set
.... ...0 .... .... = Ignore Spaces before '(': Not set
.... ..1. .... .... = Speaks 4.1 protocol (new flag): Set
.... .0.. .... .... = Interactive Client: Not set
.... 0... .... .... = Switch to SSL after handshake: Not set
...0 .... .... .... = Ignore sigpipes: Not set
..1. .... .... .... = Knows about transactions: Set
.0.. .... .... .... = Speaks 4.1 protocol (old flag): Not set
1... .... .... .... = Can do 4.1 authentication: Set
Server Language: latin1 COLLATE latin1_swedish_ci (8)

Il client richiede un accesso:

.... .... .... ...1 = Long Password: Set
.... .... .... ..0. = Found Rows: Not set
.... .... .... .1.. = Long Column Flags: Set
.... .... .... 0... = Connect With Database: Not set
.... .... ...0 .... = Don't Allow database.table.column: Not set
.... .... ..0. .... = Can use compression protocol: Not set
.... .... .0.. .... = ODBC Client: Not set
.... .... 1... .... = Can Use LOAD DATA LOCAL: Set
.... ...0 .... .... = Ignore Spaces before '(': Not set
.... ..1. .... .... = Speaks 4.1 protocol (new flag): Set
.... .0.. .... .... = Interactive Client: Not set
.... 0... .... .... = Switch to SSL after handshake: Not set
...0 .... .... .... = Ignore sigpipes: Not set
..1. .... .... .... = Knows about transactions: Set
.0.. .... .... .... = Speaks 4.1 protocol (old flag): Not set
1... .... .... .... = Can do 4.1 authentication: Set
Extended Client Capabilities: 0x81be
.... .... .... ...0 = Multiple statements: Not set
.... .... .... ..1. = Multiple results: Set
.... .... .... .1.. = PS Multiple results: Set
.... .... .... 1... = Plugin Auth: Set
.... .... ...1 .... = Connect attrs: Set
.... .... ..1. .... = Plugin Auth LENENC Client Data: Set
.... .... 1... .... = Session variable tracking: Set
1000 0001 .0.. .... = Unused: 0x0204

Il server riconosce, quindi invia una risposta, che è essenzialmente vuota ...

Packet Length: 1
Packet Number: 2
EOF marker: 254

E questo fa sì che il client finisca e chiuda il socket immediatamente:

8              2016-04-14 11:18:49.316301         0.000000              137.69.150.80                     10.106.24.79       TCP        54                51157→3306 [FIN, ACK] Seq=66 Ack=62 Win=65536 Len=0            256
9              2016-04-14 11:18:49.332901         0.016600              10.106.24.79                       137.69.150.80     TCP        60                3306→51157 [ACK] Seq=62 Ack=67 Win=5888 Len=0        23
10           2016-04-14 11:18:49.391904         0.059003              10.106.24.79                       137.69.150.80     TCP        60                3306→51157 [FIN, ACK] Seq=62 Ack=67 Win=5888 Len=0              23
11           2016-04-14 11:18:49.391904         0.000000              137.69.150.80                     10.106.24.79       TCP        54                51157→3306 [ACK] Seq=67 Ack=63 Win=65536 Len=0     256

Quindi al client di connessione non è piaciuto quel pacchetto vuoto inviato dal server.

Non ottengo questo contro un altro server mysql della stessa versione dallo stesso client. Ecco il pacchetto di risposta alla richiesta di accesso dal server 2:

Packet Length: 7
Packet Number: 2
Affected Rows: 0
Server Status: 0x0002
.... .... .... ...0 = In transaction: Not set
.... .... .... ..1. = AUTO_COMMIT: Set
.... .... .... .0.. = More results: Not set
.... .... .... 0... = Multi query - more resultsets: Not set
.... .... ...0 .... = Bad index used: Not set
.... .... ..0. .... = No index used: Not set
.... .... .0.. .... = Cursor exists: Not set
.... .... 0... .... = Last row sent: Not set
.... ...0 .... .... = database dropped: Not set
.... ..0. .... .... = No backslash escapes: Not set
.... .0.. .... .... = Session state changed: Not set
.... 0... .... .... = Query was slow: Not set
...0 .... .... .... = PS Out Params: Not set

Non gestisco questo db da solo, ma se hai suggerimenti su cose da cercare nei registri, posso richiedere tali informazioni.

Qualche idea sul perché sto ricevendo un pacchetto vuoto dal server?

mysql 
— MaQleod
fonte

Risposte:

13

Il pacchetto che pensavo fosse vuoto in realtà non lo era, era una vecchia richiesta di switch Auth :

Payload
1     [fe]
Fields
status (1) -- 0xfe
Returns
Protocol::AuthSwitchResponse with old password hash
Example
01 00 00 02 fe

L'1, 2, 254 analizzato da WireShark è in realtà 01 00 00 02 fe se si osservano le stringhe di byte effettive.

Quindi non è che ci sia un malinteso, il server capisce completamente e risponde correttamente e il client termina correttamente perché non può negoziare. Il protocollo non è troppo vecchio in quanto è stato modificato in 4.1, quindi sia 5.0 che 5.7 si capiscono perfettamente. Questo dovrebbe essere un messaggio di errore più chiaro.

Il client è troppo nuovo per usare --skip-secure-auth ( riferimento ). Hanno rimosso intenzionalmente la possibilità di negoziare prima del 5.7.

Quindi le mie opzioni sono di consentire nuove password sul server (che è una configurazione specifica dell'utente, non un'opzione server globale) o di usare un binario più vecchio.

Il problema di configurazione specifico si basa sul nome utente che mi è stato assegnato. Ad un certo punto in passato, qualcuno che utilizzava questo nome utente utilizzava un client precedente e ha cambiato il metodo della password :

B.5.2.4 Client does not support authentication protocol

The current implementation of the authentication protocol uses a password hashing algorithm that is incompatible with that used by older (pre-4.1) clients. Attempts to connect to a 4.1 or newer server with an older client may fail with the following message:

shell> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

To deal with this problem, the preferred solution is to upgrade all client programs to use a 4.1.1 or newer client library. If that is not possible, use one of the following approaches:

    To connect to the server with a pre-4.1 client program, use an account that still has a pre-4.1-style password.

    Reset the password to pre-4.1 style for each user that needs to use a pre-4.1 client program. This can be done using the SET PASSWORD statement and the OLD_PASSWORD() function. As of MySQL 5.6.6, it is also necessary to first ensure that the authentication plugin for the account is mysql_old_password:

    mysql> UPDATE mysql.user SET plugin = 'mysql_old_password'
    mysql> WHERE User = 'some_user' AND Host = 'some_host';
    mysql> FLUSH PRIVILEGES;
    mysql> SET PASSWORD FOR
        -> 'some_user'@'some_host' = OLD_PASSWORD('new_password');
— MaQleod
fonte
2

Ho riscontrato questo errore durante il tentativo di connessione a un server MySQL precedente con @@old_passwordsabilitato. Sto usando mysql-client v5.7.19 e versione Server: 5.1.73.

Ho risolto il problema creando manualmente un hash password MySQL SHA1 (usando un programma che avevo scritto allo scopo) e quindi ho eseguito questo comando sul server:

SET PASSWORD FOR 'nagios'@'10.10.10.201' = 'xxxx';

(Dov'era xxxxeffettivamente l'hash.)

— Alastair Irvine
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.