ssh_exchange_identification: read: Thiết lập lại kết nối theo ngang hàng

Tôi đang dùng OS X để thử ssh vào máy chủ Ubuntu 12.04. Tôi đã có thể SSH vào - cho đến khi mọi thứ đột ngột ngừng hoạt động. Tôi đã đọc trực tuyến để sử dụng -vđể gỡ lỗi này. Đầu ra được hiển thị dưới đây. Nếu tôi ssh vào một hộp khác và sau đó ssh từ hộp đó đến máy chủ thì tôi có thể đăng nhập. Tôi không biết làm thế nào để gỡ lỗi vấn đề này nhưng muốn tìm hiểu.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Cho đến nay (theo lời khuyên của bảng tin) Tôi đã tìm kiếm một tệp từ chối máy chủ - nhưng không có tệp nào như vậy trên máy của tôi.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

Tôi có quyền truy cập quản trị viên trên máy khách nhưng không phải trên máy chủ.

Thay đổi đột ngột có thể là kết quả của sự thay đổi tệp cấu hình trên sshdcấu hình máy chủ , nhưng bạn cho biết không thể kiểm tra hoặc thay đổi điều đó mà không có quyền quản trị viên. Bạn vẫn có thể thử các cách sau nếu không thể truy cập quản trị viên của máy chủ (kịp thời).

Nhật ký của bạn chỉ cho biết chuỗi phiên bản cục bộ, bạn nên kiểm tra các phiên bản sshdđang chạy trên máy chủ và máy trung gian.

Nếu các phiên bản khác nhau (đặc biệt là giữa các máy tính cục bộ và máy chủ và ít giữa các máy trung gian và máy chủ) có thể có một số không tương thích đàm phán, điều này đã xảy ra trước đây ở ssh. Giải pháp được sử dụng là rút ngắn các mục nhập Mật mã, HostKeyAlacticms và / hoặc MAC, trên dòng lệnh ( ssh -c aes256-ctr, v.v.) hoặc trên của bạn /etc/ssh/ssh_config.

Bạn nên xem thông tin gỡ lỗi (từ kết nối qua trung gian đến máy chủ) để biết các giá trị phù hợp làm đối số cho sự tôn trọng -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsvà -m/ MACsdòng lệnh. ssh_config thay đổi.

Tôi đã không gặp phải vấn đề này trong một thời gian, nhưng IIRC khi tôi làm điều đó là đủ để buộc thủ công cài đặt Mật mã và HostKeyAlacticms, sau đó tôi có thể cập nhật sshdphiên bản của máy chủ và sự cố đã biến mất.

Bạn có thể đã bị cấm bởi fail2banhoặc denyhosts. Trong trường hợp như vậy (và cũng để kiểm tra), nếu bạn không muốn làm phiền với sự trợ giúp của nhà cung cấp máy chủ của mình, bạn cần đăng nhập vào máy chủ của mình từ một địa chỉ IP khác: ví dụ: máy chủ khác hoặc kết nối nhà của một người bạn hoặc điểm truy cập wifi hoặc sử dụng SSH với TOR.

Sau khi đăng nhập, hãy kiểm tra xem địa chỉ IP của bạn có thực sự xuất hiện không /etc/hosts.deny(ở phía máy chủ). Nếu vậy, fail2banhoặc denyhostsphải là thủ phạm thực sự.

Xem câu trả lời cho câu hỏi này để biết quy trình ngăn denyhostschặn chặn địa chỉ của bạn liên tục. Để fail2bantìm ip của bạn với iptables -L --line-numbervà unban bạn ip với iptables -D <chain> <chain number>, bạn kiểm tra chi tiết trên howtoforge .

Bạn có thể muốn thêm địa chỉ IP của mình vào fail2banvà denyhostsdanh sách trắng (tương ứng /etc/fail2ban/jail.conf, dòng ignoreipvà /var/lib/denyhosts/allowed-hoststạo địa chỉ nếu cần (nhưng hãy cẩn thận rằng đường dẫn có thể khác trên bản phân phối của bạn)) để ngăn sự cố xảy ra lần nữa.

Trên máy chủ lưu trữ, hãy xóa ssh pub.key nằm ở đây: ~/.ssh/authorized_keyscho máy mac của bạn. Sau đó, tail -f /var/log/auth.logtrong khi bạn mở một thiết bị đầu cuối khác và cố gắng ssh một lần nữa ssh -v me@server. Nếu bạn được nhắc nhập mật khẩu thì đã xảy ra sự cố với khóa ssh của bạn. Nếu bạn vẫn thấy 'ssh_exchange_identification: read: Thiết lập lại kết nối theo phản hồi ngang hàng, thì bạn sẽ có thể xác định vấn đề là gì từ mục nhật ký trong tệp' /var/log/auth.log 'sau khi bạn thất bại để đăng nhập.

Nếu bạn vẫn không kết nối được, hãy đăng mục đã đăng nhập từ tệp auth vào đây và tôi sẽ sửa lại câu trả lời của mình.

Điều này có thể xảy ra nếu bạn có nhiều máy trên mạng có cùng địa chỉ MAC (ví dụ: nếu bạn tạo một bản sao của máy ảo và quên thay đổi MAC).

Tôi đã nhận được điều này do máy chủ tên ISP của tôi trong /etc/resolv.conf. Các máy chủ tên này thường bị quá tải và nếu tra cứu DNS ngược sshdsẽ làm mất kết nối. Tôi đã giải quyết vấn đề bằng cách sử dụng máy chủ tên đáng tin cậy hơn, vd 8.8.8.8.

Tôi đã phải đối mặt với cùng một vấn đề. Tôi sẽ mở phiên ssh thành công nhưng nó sẽ được thiết lập lại sau một thời gian. Khi tôi cố gắng kết nối gain ngay lập tức tôi sẽ gặp lỗi "Kết nối bị từ chối". Khi tôi gỡ lỗi phiên tôi nhận được thông báo này tại thời điểm kết nối được thiết lập lại

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1                                                           

Tại thời điểm này tôi nhận ra rằng có một xung đột địa chỉ IP trên mạng. Tôi đã đổi sang một địa chỉ khác và vấn đề đã được giải quyết

Nhật ký của bạn có nghĩa là phía máy chủ giảm kết nối. Để tìm hiểu lý do, bạn nên tham khảo nhật ký phía máy chủ, họ nên đưa ra lý do ngắt kết nối. Bạn hầu như luôn có thể tìm thấy nhật ký trong / var / log / message

Tôi có thể đoán rằng, khi kết nối bị mất ngay sau khi máy khách gửi số phiên bản, máy chủ bằng cách nào đó đe dọa máy khách là không tương thích.

Tôi có cùng một vấn đề nhưng hóa ra nguyên nhân lại khác: tôi đã sử dụng cổng sai.

Trên các phiên bản mới hơn của sshlỗi được đưa ra là Connection refusedhoặc Bad port.

Trên các phiên bản cũ, lỗi được đưa ra là ssh_exchange_identification: read: Connection reset by peer

Vì vậy, khi bạn nhận được kiểm tra lỗi như vậy nếu cổng là chính xác.

Tôi biết câu hỏi này đã cũ, nhưng tôi muốn chia sẻ một số phát hiện tôi có. Kiểm tra xem /var/empty/sshdtrên máy chủ có quyền sở hữu và quyền thích hợp.

Chúng tôi đã có một tập lệnh đầu bếp đã được sửa đổi để cập nhật một số quyền của thư mục, nhưng vô tình cập nhật thư mục bên dưới mục tiêu dự định, thay đổi quyền sở hữu / var thành người dùng / nhóm ứng dụng và thay đổi quyền thành 775.

Vì nó không được đề cập rõ ràng trong Câu trả lời, một cách khác mà lỗi này có thể xuất hiện là nếu tường lửa dựa trên mạng giữa bạn và máy chủ đã quyết định chặn kết nối. Tường lửa có thể đã quyết định rằng có "quá nhiều" kết nối từ IP của hệ thống OS X và bắt đầu chặn nó. Vẫn chưa có "quá nhiều" kết nối từ hệ thống khác, và vì vậy nó đã được cho phép.

Tin nhắn cuối cùng bạn nhận được từ máy chủ là một tin nhắn xuất hiện trước cả khi bạn bắt đầu bất kỳ nỗ lực xác thực nào, quy định một lớp lớn các khả năng xung quanh tài khoản, khóa hoặc mật khẩu của bạn.

Ví dụ về các chính sách vũ phu như vậy từ một mẫu ngẫu nhiên của các nhà cung cấp là:

• CloudFlare: Làm cách nào để tôi sử dụng Tỷ lệ giới hạn để bảo vệ chống lại các cuộc tấn công vũ phu?
• F5: Cấu hình bảo vệ tấn công vũ phu
• FortiNet: tạo chữ ký IPS tùy chỉnh để phát hiện tỷ lệ mẫu - ví dụ để phát hiện cuộc tấn công Brute-force
• Palo Alto: Ngăn chặn các cuộc tấn công vũ phu
• Sonicwall: Cách chặn các cuộc tấn công của Brute Force và Dictionary với SRA