Máy chủ phản hồi với gói trống trong quá trình đàm phán phiên dẫn đến việc máy khách đưa ra lỗi gói không đúng định dạng


14

Tôi đang cố gắng kết nối với một máy chủ mysql từ xa. Điều này xảy ra 100% thời gian.

máy khách: mysql Ver 14,14 Phân phối 5.7.12, cho
máy chủ Win32 (AMD64) : 5.0.95

Đây là lỗi tôi nhận được:

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

lỗi tương tự với 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'

Vì vậy, tôi đã lấy một pcap, chỉ để có được một ý tưởng về cuộc trò chuyện đó trông như thế nào.

Bắt tay TCP:

1              2016-04-14 11:18:48.910690         0.000000              137.69.150.80                     10.106.24.79       TCP        66                511573306 [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                330651157 [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                511573306 [ACK] Seq=1 Ack=1 Win=65536 Len=0          256

Đàm phán kết nối 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                330651157 [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

Vì vậy, máy khách kết nối ở cấp TCP, máy chủ chào đón chúng tôi với các tùy chọn và trạng thái được hỗ trợ:

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)

Khách hàng yêu cầu đăng nhập:

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

Máy chủ thừa nhận, sau đó gửi phản hồi, về cơ bản là trống rỗng

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

Và điều đó ngay lập tức khiến máy khách FIN và đóng ổ cắm:

8              2016-04-14 11:18:49.316301         0.000000              137.69.150.80                     10.106.24.79       TCP        54                511573306 [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                330651157 [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                330651157 [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                511573306 [ACK] Seq=67 Ack=63 Win=65536 Len=0     256

Vì vậy, máy khách kết nối không giống như gói trống mà máy chủ đã gửi.

Tôi không nhận được điều này với một máy chủ mysql khác có cùng phiên bản từ cùng một máy khách. Đây là gói phản hồi cho yêu cầu đăng nhập từ máy chủ 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

Tôi không tự quản lý db này, nhưng nếu bạn có đề xuất về những thứ cần tìm trong nhật ký, tôi có thể yêu cầu thông tin đó.

Bạn có suy nghĩ gì về việc tại sao tôi lại nhận được một gói trống từ máy chủ không?

Câu trả lời:


13

Gói mà tôi nghĩ trống thực ra không phải, đó là một Yêu cầu chuyển đổi Auth cũ :

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

Số 1, 2, 254 mà wireshark đã phân tích thực sự là 01 00 00 02 fe nếu bạn nhìn vào chuỗi byte thực tế.

Vì vậy, không có sự hiểu lầm, máy chủ hiểu hoàn toàn và phản hồi chính xác và khách hàng chấm dứt chính xác vì không thể thương lượng được. Giao thức không quá cũ vì nó đã được thay đổi trong 4.1, vì vậy cả 5.0 và 5.7 đều hiểu nhau một cách hoàn hảo. Đây phải là một thông báo lỗi rõ ràng hơn.

Máy khách quá mới để sử dụng --skip-safe-auth ( tham khảo ). Họ cố tình loại bỏ khả năng đàm phán xuống trước 5.7.

Vì vậy, các tùy chọn của tôi là cho phép mật khẩu mới trên máy chủ (là cấu hình cụ thể của người dùng, không phải tùy chọn máy chủ toàn cầu) hoặc sử dụng tệp nhị phân cũ hơn.

Vấn đề cấu hình cụ thể được dựa trên tên người dùng tôi đã được cung cấp. Tại một số thời điểm trước đây, một người nào đó sử dụng tên người dùng này đang sử dụng một khách hàng cũ và họ đã thay đổi phương thức mật khẩu :

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

2

Tôi đã gặp lỗi này khi cố gắng kết nối với máy chủ MySQL cũ hơn với @@old_passwords đã bật. Tôi đang sử dụng mysql-client v5.7.19 và phiên bản Máy chủ: 5.1.73.

Tôi đã khắc phục sự cố bằng cách tạo thủ công băm mật khẩu MySQL SHA1 (sử dụng chương trình tôi đã viết cho mục đích này) và sau đó tôi chạy lệnh này trên máy chủ:

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

(Trường hợp xxxxthực sự là hàm băm.)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.