เซิร์ฟเวอร์ตอบสนองด้วยแพ็คเก็ตที่ว่างเปล่าในระหว่างการเจรจาเซสชันส่งผลให้ลูกค้าให้ข้อผิดพลาดของแพ็คเก็ตที่ผิดรูปแบบ

ฉันพยายามเชื่อมต่อกับเซิร์ฟเวอร์ mysql ระยะไกล สิ่งนี้เกิดขึ้น 100% ของเวลา

ลูกค้า: mysql Ver 14.14 Distrib 5.7.12, สำหรับ
เซิร์ฟเวอร์Win32 (AMD64) : 5.0.95

นี่เป็นข้อผิดพลาดที่ฉันได้รับ:

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

ข้อผิดพลาดเดียวกันกับ 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'

ดังนั้นฉันจึงหยิบ pcap ขึ้นมาเพื่อรับทราบว่าบทสนทนานั้นเป็นอย่างไร

จับมือ 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

การเจรจาการเชื่อมต่อ 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

ดังนั้นลูกค้าเชื่อมต่อที่ระดับ TCP เซิร์ฟเวอร์ต้อนรับเราด้วยตัวเลือกและสถานะที่รองรับ:

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)

ลูกค้าขอเข้าสู่ระบบ:

.... .... .... ...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

เซิร์ฟเวอร์ตอบรับจากนั้นส่งการตอบกลับซึ่งโดยพื้นฐานแล้วว่างเปล่า ...

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

และนั่นทำให้ไคลเอนต์ FIN ทันทีและปิดซ็อกเก็ต:

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

ดังนั้นไคลเอ็นต์ที่เชื่อมต่อจึงไม่ชอบแพ็คเก็ตที่ว่างเปล่าที่เซิร์ฟเวอร์ส่งไป

ฉันไม่ได้รับมันกับเซิร์ฟเวอร์ mysql รุ่นเดียวกันจากไคลเอนต์เดียวกัน นี่คือแพ็คเก็ตการตอบสนองต่อคำขอเข้าสู่ระบบจากเซิร์ฟเวอร์ 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

ฉันไม่ได้จัดการฐานข้อมูลนี้ด้วยตนเอง แต่ถ้าคุณมีข้อเสนอแนะสำหรับสิ่งที่ต้องค้นหาในบันทึกฉันสามารถขอข้อมูลนั้นได้

มีความคิดเกี่ยวกับสาเหตุที่ฉันรับแพ็กเก็ตที่ว่างเปล่ากลับมาจากเซิร์ฟเวอร์หรือไม่

แพ็คเก็ตที่ฉันคิดว่าว่างเปล่าจริง ๆ แล้วไม่ใช่มันเป็นคำขอ Auth Switch เก่า :

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

1, 2, 254 ที่แยก wireshark เป็นจริง 01 00 00 02 fe ถ้าคุณดูสตริงไบต์จริง

ดังนั้นจึงไม่ใช่ว่ามีความเข้าใจผิดเซิร์ฟเวอร์เข้าใจอย่างสมบูรณ์และตอบสนองอย่างถูกต้องและลูกค้ายกเลิกอย่างถูกต้องเพราะไม่สามารถเจรจาต่อรองได้ โปรโตคอลไม่เก่าเกินไปเนื่องจากมีการเปลี่ยนแปลงใน 4.1 ดังนั้นทั้ง 5.0 และ 5.7 จึงเข้าใจกันอย่างสมบูรณ์ นี่ควรเป็นข้อความแสดงข้อผิดพลาดที่ชัดเจนขึ้น

ลูกค้าใหม่เกินไปที่จะใช้ --skip-secure-auth ( ข้อมูลอ้างอิง ) พวกเขาตั้งใจลบความสามารถในการเจรจาลงก่อนหน้า 5.7

ดังนั้นตัวเลือกของฉันคืออนุญาตรหัสผ่านใหม่บนเซิร์ฟเวอร์ (ซึ่งเป็นการกำหนดค่าเฉพาะผู้ใช้ไม่ใช่ตัวเลือกเซิร์ฟเวอร์ทั่วโลก) หรือใช้ไบนารีเก่า

ปัญหาการกำหนดค่าเฉพาะนั้นขึ้นอยู่กับชื่อผู้ใช้ที่ฉันได้รับ เมื่อก่อนหน้านี้บางคนที่ใช้ชื่อผู้ใช้นี้กำลังใช้ไคลเอ็นต์รุ่นเก่าและพวกเขาเปลี่ยนวิธีการใช้รหัสผ่าน :

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');

ฉันได้รับข้อผิดพลาดนี้เมื่อพยายามเชื่อมต่อกับเซิร์ฟเวอร์ MySQL รุ่นเก่าที่@@old_passwordsเปิดใช้งาน ฉันใช้ mysql-client v5.7.19 และรุ่นเซิร์ฟเวอร์: 5.1.73

ฉันแก้ไขปัญหาด้วยการสร้างแฮชรหัสผ่าน MySQL SHA1 ด้วยตนเอง (โดยใช้โปรแกรมที่ฉันเขียนเพื่อวัตถุประสงค์) จากนั้นฉันก็รันคำสั่งนี้บนเซิร์ฟเวอร์:

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

(ที่xxxxจริงแล้วแฮชอยู่ตรงไหน)