Mặc dù trong nhiều trường hợp, lỗi ssh_exchange_identification: Kết nối bị đóng bởi lỗi máy chủ từ xa có thể do các vấn đề liên quan đến tệp cấu hình hosts.deny và hosts.allow gây ra, có những thứ khác có thể gây ra sự cố. Nếu bạn đang đọc nó, thì rất có thể bạn đã kiểm tra để đảm bảo rằng cả hai tệp này đều không chặn địa chỉ IP của bạn cố gắng sử dụng ssh trên một máy chủ từ xa.
Giả sử trường hợp này xảy ra, thì bạn có thể đang xem xét một vấn đề phụ thuộc, một cái gì đó liên quan đến phân mảnh bộ nhớ hoặc thậm chí quá nhiều phiên đến từ các máy khách riêng lẻ. Tin tốt là khi bạn đã xử lý xong vấn đề, bạn sẽ không gặp lỗi nữa.
Phương pháp 1: Khắc phục Thiếu phụ thuộc
Nếu bạn nhận được ssh_exchange_identification: kết nối bị đóng bởi lỗi máy chủ từ xa chỉ sau khi cập nhật OpenSSL hoặc glibc, thì bạn có thể đang xem xét một phần phụ thuộc bị thiếu. Chạy sudo lsof -n | grep ssh | grep DEL khỏi dòng lệnh trong tình huống này. Thao tác này sẽ cung cấp cho bạn danh sách các tệp đang mở, sau đó chỉ tìm những tệp đã bị xóa gần đây có liên quan đến daemon ssh.
Nếu bạn không lấy lại được gì, bạn vẫn có thể thử khởi động lại daemon hoặc chính hệ thống. Bạn sẽ muốn thử khởi động lại nếu một số lỗi xảy ra với bạn, mặc dù vậy bạn có thể bỏ qua một cách an toàn những thông báo liên quan đến / run / user / 1000 / gvfs vì những lỗi này là do sự cố không liên quan gây ra làm với một hệ thống tệp ảo.
Bạn cũng có thể cố gắng sử dụng apt-get, pacman hoặc yum để cập nhật các gói của mình nếu bạn nghi ngờ các phần phụ thuộc là một vấn đề. Nếu bạn đang sử dụng hệ thống dựa trên Debian hoặc Ubuntu, thì bạn có thể muốn thử nâng cấp sudo apt-get -f và xem liệu cách đó có khắc phục được bất kỳ gói bị hỏng nào mà bạn có thể mắc phải hay không.
Phương pháp 2: Khắc phục sự phân mảnh bộ nhớ
Nếu điều này không hữu ích, thì bạn có thể gặp sự cố ở phía máy chủ của phương trình. Máy chủ chạy bên trong máy ảo không phải lúc nào cũng có phân vùng hoán đổi, điều này có thể dẫn đến phân mảnh bộ nhớ. Truy cập máy chủ lưu trữ bằng một số phương tiện khác, có thể là vật lý nếu có thể, sau đó khởi động lại bất kỳ dịch vụ nào đang gặp sự cố. MySQL, Apache, nginx và các dịch vụ khác có thể là thủ phạm.
Mặc dù việc khởi động lại máy chủ không phải lúc nào cũng khả thi, nhưng điều này có thể khắc phục sự cố và có thể là một ý tưởng hay nếu bạn đang xen kẽ giữa thông báo lỗi này và thông báo trả về địa chỉ IP. Hãy nhớ rằng nếu bạn có bất kỳ loại quyền truy cập nào vào máy chủ, thì bạn có thể chạy lệnh vmstat -s và nhận một số thống kê quan trọng về cách bộ nhớ được sử dụng ngay cả khi là người dùng thông thường trong nhiều trường hợp.
Phương pháp 3: Kiểm tra các phiên bản ssh bổ sung
Bỏ qua điều này, sau đó kiểm tra xem máy chủ có đang cố gắng kết nối với máy chủ hay không. Bạn có thể đã vượt quá số phiên ssh tối đa mà không biết. Xóa các phiên cũ và sau đó thử kết nối lại. Một cách dễ dàng để thực hiện việc này là chạy lệnh who để xem quy trình người dùng nào đã đăng nhập. Bạn sẽ chỉ thấy một hoặc hai người dùng đã đăng nhập. Nếu có một số người dùng song song, hãy tắt các quy trình người dùng và thử đăng nhập lại .
Điều này có thể xảy ra nếu sshd không thể theo kịp tập lệnh bắt đầu nhiều phiên ssh khác nhau trong một vòng lặp. Nếu điều này từng xảy ra với bạn, hãy thêm lệnh sleep 0.3 vào vòng lặp để trình nền sshd có thời gian theo kịp.
Phương pháp 4: Tìm giới hạn kết nối sshd
Các sự cố kết nối như thế này đặc biệt phổ biến khi cố gắng sử dụng ssh để truy cập bộ định tuyến hoặc một loại công tắc đóng hộp rời khác vì số lượng kết nối tối đa mặc định quá nhỏ. Mặc dù bạn không muốn cho phép mình quá tải máy chủ, bạn có thể xem cài đặt mặc định là gì.
Thử chạy 
trên máy chủ để tìm số lượng kết nối mà sshd có thể xử lý. Trong hầu hết các trường hợp, hệ thống nên mặc định có 10 kết nối đồng thời, điều này sẽ đủ cho hầu hết các cấu trúc máy chủ mà đa số người dùng có thể cần sử dụng ssh thường xuyên.