ssh_exchange_identification: Kết nối được đóng bởi máy chủ từ xa (không sử dụng hosts.deny)

Tôi không sử dụng hosts.allowhoặc hosts.denyhơn nữa SSH hoạt động từ máy tính windows của tôi (cùng máy tính xách tay, ổ cứng khác nhau) nhưng không phải máy Linux của tôi.

ssh -vvv root@host -p port cho:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

Trên máy windows mọi thứ đều hoạt động tốt, vì vậy tôi đã kiểm tra nhật ký bảo mật và các dòng trong đó giống hệt nhau, máy chủ xử lý hai "máy" khác nhau không khác nhau và cả hai đều được cho phép thông qua xác thực khóa công khai ..

Vì vậy, điều đó dẫn đến kết luận rằng đây phải là một vấn đề với máy tính xách tay ArchLinux địa phương của tôi .. nhưng những gì?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Vì vậy, đó không phải là vấn đề ..

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Không có xung đột với các cài đặt tường lửa (hiện tại) ..

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

Quyền có vẻ ổn (tương tự trên máy chủ) .. Cũng đã thử mà không cấu hình /etc/ssh/ssh_configvới cùng kết quả ngoại trừ rất nhiều cấu hình tự động đang diễn ra trong máy khách có cùng lỗi.

Nếu bạn đã loại trừ bất kỳ yếu tố "bên ngoài" nào, tập hợp các bước sau đây thường giúp thu hẹp nó. Vì vậy, trong khi điều này không trả lời trực tiếp câu hỏi của bạn, nó có thể giúp theo dõi nguyên nhân lỗi.

Xử lý sự cố sshd

Những gì tôi thấy nói chung rất hữu ích trong bất kỳ trường hợp nào như vậy là bắt đầu sshdmà không để nó trình bày. Các vấn đề trong trường hợp của tôi là không phải syslogvà cũng không auth.logcho thấy bất cứ điều gì có ý nghĩa.

Khi tôi khởi động nó từ thiết bị đầu cuối, tôi nhận được:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Tốt hơn nhiều! Thông báo lỗi này cho phép tôi xem những gì sai và sửa nó. Cả hai tệp nhật ký đều chứa đầu ra này.

NB: ít nhất là trên Ubuntu, đây $(which sshd)là phương pháp tốt nhất để đáp ứng sshdyêu cầu của một đường dẫn tuyệt đối. Nếu không, bạn sẽ nhận được lỗi sau : sshd re-exec requires execution with an absolute path. Các -p 10222làm cho sshdnghe trên cổng đó thay thế, trọng tập tin cấu hình - đây là để nó không mâu thuẫn với khả năng chạy sshdtrường. Hãy chắc chắn để chọn một cổng miễn phí ở đây.

Cuối cùng: kết nối với cổng thay thế ( ssh -p 10222 user@server).

Phương pháp này đã giúp tôi nhiều lần trong việc tìm kiếm các vấn đề, có thể là các vấn đề xác thực hoặc các loại khác. Để có được đầu ra thực sự dài dòng stdout, hãy sử dụng $(which sshd) -Ddddp 10222(lưu ý thêm vào ddđể tăng độ dài). Để kiểm tra độ tốt gỡ lỗi hơn man sshd.

Bạn cũng có thể có một máy chủ lưu trữ bộ nhớ bị phân mảnh nghiêm trọng đến mức nó không thể phân bổ một trang bộ nhớ liền kề để phân nhánh quá trình lưu trữ phiên SSH.

Trong trường hợp như vậy, bạn có thể nhận được một trong các tin nhắn:

ssh_exchange_identification: read: Connection reset by peer

hoặc là:

Connection closed by aaa.bbb.ccc.ddd

tùy thuộc vào khoảng cách mà máy chủ nhận được trước khi nó thoát ra.

Nếu phân mảnh bộ nhớ là nguyên nhân rõ ràng, giải pháp là truy cập máy chủ thông qua các phương tiện khác và khởi động lại một số dịch vụ thích hợp. Tôi đã tìm thấy Apache và MySQL là thủ phạm của VM vì VM không có phân vùng trao đổi. Không, khởi động lại máy chủ.

Chỉ trong trường hợp, bởi vì điều này xảy ra với tôi. Hãy chắc chắn rằng bạn có sshd chạy trong máy chủ!

Đó là một thất bại ngu ngốc, nhưng có thể thực sự là vấn đề của bạn.

Tôi thấy rằng lỗi này là do các phiên ssh vượt quá máy chủ. Tôi tìm thấy các máy chủ đang cố gắng kết nối và giết tất cả các phiên từ tất cả các khách hàng. Vấn đề được giải quyết sau khi xóa tất cả các phiên.

Tôi đã chạy qua ssh_exchange_identification: read: Connection reset by peervấn đề trong một kịch bản bắt đầu 16 phiên ssh trở lên trong một vòng lặp. sshd dường như không thể theo kịp; thêm một giấc ngủ ngắn đã giải quyết vấn đề của tôi:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done

Hoặc bạn có thể đã làm những gì tôi đã làm, tối qua và xóa / var / trống. Rõ ràng thư mục đó và các quyền của nó rất cần thiết cho hoạt động của sshd và nó sẽ không làm lại thư mục khi được khởi động lại /etc/init.d/sshdsẽ không khởi động lại được và không có gì systemd sẽ cho bạn biết lý do.

Tôi đã tìm thấy vấn đề bằng cách chạy sshd ở nền trước:

# /usr/sbin/sshd -Dd
  Missing privilege separation directory: /var/empty/sshd

Xây dựng lại các thư mục đã giải quyết vấn đề trong trường hợp của tôi:

drwxr-xr-x. root root  /var/empty
drwx--x--x. root root  /var/empty/sshd

Lưu ý cho các lập trình viên Linux: Những thứ cực kỳ quan trọng trong /var/empty... thực sự ???

Tôi đã gặp lỗi ssh_exchange_identification: Connection closed by remote hostkhi cố gắng kết nối với SSH: Tôi đã thực hiện chuyển tiếp cổng từ xa cho cổng SSH 22 của máy tính cục bộ để tôi có thể truy cập tạm thời từ máy chủ từ xa trên Internet.

Trong thực tế, lỗi chỉ được hiển thị vì tôi không nhớ rằng tôi đã tắt dịch vụ SSH khi khởi động nên tôi phải khởi động dịch vụ SSH trên máy tính cục bộ của mình : sudo service ssh start.

Điều đầu tiên trước tiên; telnet đến địa chỉ IP của máy chủ để xác minh xem cổng 22 có thực sự lắng nghe (đã mở) trên máy chủ đó không:

telnet x.x.x.x 22

(nếu không, sau đó bạn có thể nối cáp điều khiển để đăng nhập)

Trong trường hợp của tôi, nó không hoạt động và tôi đã nối cáp điều khiển để đăng nhập. Khi tôi đăng nhập, tôi phát hiện ra rằng tất cả 5 dòng VTY đang bận trên máy chủ đó (bộ định tuyến của Cisco).

Tôi đã xóa các kết nối cũ được treo ở đó để giải phóng các dòng VTY, nó đã hoạt động. Tôi đã thêm lệnh "exec-timeout 15" bên dưới các dòng VTY. Sau đó, tôi loại bỏ cáp điều khiển.

Bài học:

Đảm bảo đặt thời gian chờ 5-10 phút trên tất cả các thiết bị của bạn - (nếu không phát hiện thấy hoạt động nào).

Trường hợp của tôi đã bị đặt nhầm socket socket (không hoạt động). Tôi nhận được chính xác đầu ra ssh -vvv và nhật ký sshd trống.

Lỗi ssh_exchange_identification: Connection closed by remote hostcó thể xảy ra vì một số lý do chưa biết. Khi tôi đang sử dụng mã Visual Studio . Lỗi tương tự xảy ra khi tôi cố gắng kéo từ repo từ xa bằng cách sử dụng git pulllệnh.

Tôi vừa đóng thiết bị đầu cuối nhúng và mở thiết bị đầu cuối của Ubuntu và kéo lại. Và nó đã thành công

Từ phía sau CentOS Linux release 7.4.1708 (Core)với OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017một kết nối không lọc các cổng tôi có:

ssh_exchange_identification: Kết nối được đóng bởi máy chủ từ xa

Và hóa ra Raspberry Pi của tôi đã tắt!

Tôi đã nghĩ rằng một máy chủ không được bật nguồn sẽ gây ra lỗi "Không có tuyến đến máy chủ". Raspberry Pi đứng sau bộ định tuyến ISP của tôi nên có lẽ nó đã đóng kết nối.

Sau đó, tôi lặp lại thử nghiệm (cố gắng kết nối với Raspberry Pi đã tắt nguồn) từ một kết nối internet khác cũng không lọc các cổng với Debian Stretch OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017và lần này tôi đã mong đợi:

Không có tuyến đường đến máy chủ