Tôi gặp một số rắc rối với SSH trên máy chủ linux chạy CentOS. Tôi có thể kết nối tốt với máy chủ của mình bằng PuTTY hoặc ssh từ windows cmd. Điều tương tự cũng xảy ra đối với việc sử dụng FTP an toàn. Tôi có thể kết nối với máy chủ, lấy danh sách các tập tin và mọi thứ đều ổn. Vấn đề xảy ra khi tôi cố gắng gửi bất kỳ số lượng dữ liệu trên mạng.
Bất cứ khi nào tôi cố gắng chuyển bất cứ thứ gì vượt quá một ngưỡng nhất định, kết nối sẽ thất bại và tôi thấy thông báo 'Thiết lập lại kết nối theo ngang hàng'. Tôi có một tập tin sql khoảng 3 MB trong thư mục nhà của tôi. Nếu tôi cố gắng FTP nó, nó sẽ bắt đầu chuyển và chết sau khi khoảng 48k đã được chuyển. Sau đó, nó sẽ bắt đầu một kết nối mới và chuyển 48k khác. Nếu tôi sử dụng PuTTY và mở một phiên, tôi có thể kết nối và đăng nhập tốt. Nếu tôi cố gắng thực hiện cat file.sqllại, kết nối sẽ bị chấm dứt và tôi nhận được thông báo 'Thiết lập lại kết nối theo ngang hàng. Đi từ máy trạm cục bộ của tôi đến máy chủ thì tình huống tương tự. Tôi có khá nhiều mã nguồn mà tôi cần phải cam kết với kho svn của mình được lưu trữ trên máy chủ, nhưng cùng một thông báo 'Thiết lập lại kết nối bằng ngang hàng' xuất hiện.
Tôi biết vấn đề nằm ở máy trạm cục bộ của tôi vì tôi có thể sử dụng macbook và ssh của vợ tôi cho máy chủ mà không gặp vấn đề gì. Tôi có thể ssh vào hộp linux của một người bạn (sử dụng cùng cài đặt putty) và sftp đến máy chủ của tôi từ họ và tải tệp xuống, mở một phiên ssh khác từ hộp của anh ta đến máy chủ của tôi và gửi tệp. Vì vậy, một cái gì đó đang xảy ra, nhưng tôi không chắc chắn những gì. Có ai có ý tưởng nào?
Cập nhật
Tôi đã cố gắng tìm hiểu thêm điều này và có vẻ như có giới hạn cứng về lượng dữ liệu mà tôi có thể chuyển trong một phiên ssh duy nhất. Tôi nhấn nó ngay lập tức nếu tôi làm cat file.sqlnhưng tôi cũng có thể tiếp tục nhập ls -lmột số lần nhất quán và cũng sẽ nhận được thông báo 'Thiết lập lại kết nối theo ngang hàng'. Tôi đã thử:
- tạo khóa ssh mới
- khởi động lại bộ định tuyến của tôi
- khởi động lại máy tính của tôi
- khởi động lại máy chủ từ xa
Tôi đã viết một tcpdump trên máy chủ từ xa, nhưng tôi không hiểu TCP ở mức độ chi tiết đến mức nó có ý nghĩa với tôi. Tôi đã bật gỡ lỗi trong ssh và đây là phần nhật ký dẫn đến kết nối được đặt lại:
Jul 24 23:10:56 server sshd[4507]: debug1: permanently_set_uid: 500/503
Jul 24 23:10:56 server sshd[4507]: debug1: Entering interactive session for SSH2.
Jul 24 23:10:56 server sshd[4507]: debug1: server_init_dispatch_20
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Jul 24 23:10:56 server sshd[4507]: debug1: input_session_request
Jul 24 23:10:56 server sshd[4507]: debug1: channel 0: new [server-session]
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: session 0: link with channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: confirm session
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req pty-req
Jul 24 23:10:56 server sshd[4507]: debug1: Allocating pty.
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_pty_req: session 0 alloc /dev/pts/2
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request shell reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req shell
Jul 24 23:10:56 server sshd[4508]: debug1: Setting controlling tty using TIOCSCTTY.
Jul 24 23:10:59 server sshd[4507]: Read error from remote host <my-ip>: Connection reset by peer
Jul 24 23:10:59 server sshd[4507]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: deleting credentials
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: closing session
Jul 24 23:10:59 server sshd[4505]: pam_unix(sshd:session): session closed for user <me>
Jul 24 23:10:59 server sshd[4505]: debug1: session_pty_cleanup: session 0 release /dev/pts/2
CẬP NHẬT 2:
Khoảng một tuần trước, tôi đã sửa đổi cài đặt ssh của mình trên máy chủ bằng cách sử dụng bài đăng wiki này: http://wiki.centos.org/HowTos/Network/SecuringSSH
Vì thỉnh thoảng tôi cần truy cập máy chủ của mình từ công việc và vì cổng 21 mở trên tường lửa của chúng tôi, tôi đã thay đổi cổng ssh thành 21. Để chẩn đoán thêm vấn đề này, tôi đã cố gắng hoàn nguyên cài đặt ssh của mình và thay đổi cổng ssh trở lại 22 Thấp và kìa, tôi không gặp phải lỗi khi tôi sử dụng cổng 22. Thay đổi lại thành 21 và giống như chế độ đồng hồ khi tôi đạt 48k dữ liệu được truyền - Thiết lập lại kết nối bằng ngang hàng.
Vì tôi có thể nhận được kết nối ban đầu và trước đây tôi không gặp khó khăn gì khi thiết lập kết nối ftp trên cổng 21, có vẻ như cấu hình tường lửa của tôi là vấn đề.
Ít nhất tại thời điểm này, tôi đã gặp sự cố thu hẹp vào cổng ssh trên máy chủ của mình. Lật nó thành 21 và các vấn đề tức thời, thay đổi lại thành 22, không có vấn đề gì cả ...
Bất cứ ai cũng có thể nghĩ tại sao cổng nghe sẽ làm cho một sự khác biệt? Một lần nữa, chỉ trên hộp Windows XP của tôi, nó mới gây ra sự cố. Hãy cho tôi biết nếu có ai có bất kỳ suy nghĩ về những gì có thể gây ra điều này.
Cập nhật 2:
Chỉ cần thu hẹp vấn đề và tôi đứng ra khắc phục - đó là sự cố tường lửa, nhưng sự cố tường lửa của Windows, không phải ở bộ định tuyến của tôi. Nếu tôi sử dụng cổng 21 và vô hiệu hóa tường lửa windows, tôi sẽ không gặp phải thông báo 'Thiết lập lại kết nối bằng ngang hàng'. Để trả lời câu hỏi rõ ràng, vâng, cổng 21 được mở trên tường lửa của windows.
Vì máy tính này đứng sau tường lửa trên bộ định tuyến của tôi, tôi có thể vô hiệu hóa nó ngay bây giờ, nhưng tôi sẽ quan tâm để tìm hiểu những gì đang xảy ra ở đây.