Kết nối SSH: ssh_exchange_identifcation


9

Tôi đã kết nối với một máy chủ từ xa thông qua máy Mac của tôi khoảng một tháng nay. Gần đây, tôi đã cố gắng kết nối bằng ssh dylan @ MY_IP và nhận được tin nhắn này.

ssh_exchange_identification: read: Connection reset by peer

Tôi cũng có một số thông tin chẩn đoán ...

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 *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

Sau khi thực hiện một số nghiên cứu, tôi đã thử ...

  1. Khởi động lại bộ định tuyến của tôi
  2. Đã xóa tập tin "know_hosts" của tôi
  3. Đã xóa tệp "know_hosts" của tôi
  4. Phát hành và làm mới DHCP của tôi
  5. Tôi cũng đã thử từ một thiết bị khác (Windows) bằng Putty cũng có lỗi

Lưu ý rằng tôi chưa thực hiện bất kỳ thay đổi nào đối với máy chủ để ngăn chặn việc liên lạc này.

Ngoài ra, tôi không chắc điều này có gây ra sự cố hay không, nhưng tôi đã kết nối với nó bằng tên miền cũng như IP.

Ngoài ra, tôi có thể kết nối thành công từ một địa chỉ IP khác.

Tôi biết đây là một vấn đề lớn với nhiều tài nguyên ngoài kia, nhưng rất nhiều giải pháp không hoạt động và tôi cũng không thực sự thấy bất kỳ loại giải pháp nào cho bất kỳ ai.

Cập nhật

Tôi đã buộc nó vào giao thức 1. Thay vì "Thiết lập lại kết nối bằng ngang hàng", giờ đây tôi nhận được "Kết nối được đóng bởi máy chủ từ xa". Chạy nó với thông tin gỡ lỗi được tiết lộ:

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 *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host

Bạn có sử dụng xác thực khóa công khai không? Bạn có chìa khóa /Users/watson/.ssh/id_dsanào không? Cố gắng sao lưu tập tin và loại bỏ nó.
pabouk

Tôi không sử dụng xác thực khóa công khai; tuy nhiên, có một khóa duy nhất trong tệp. Tôi đã thử xóa tệp, nhưng không có thay đổi nào khi chạy lệnh.
Dylan

nếu đó là sự cố với phiên bản giao thức, bạn có thể buộc phải kết nối với phiên bản giao thức 1 vớissh -1 ...
wkaha

Tham khảo chỉnh sửa mới trên bài viết.
Dylan

Câu trả lời:


4

Đây là cách tôi giải quyết lỗi "ssh_exchange_identification: Kết nối bị đóng bởi máy chủ từ xa" khi kết nối với máy chủ SSH.

Tôi đã gặp lỗi này khi cố gắng kết nối với máy Linux nhúng, sau khi giải nén gói để root. Rất nhiều tệp thư viện đã được thay thế, bao gồm libssl.

Đang cố gắng kết nối:

chetic@ubuntu:~$ ssh -v root@192.168.1.100
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer

Googling dường như chỉ đề nghị kiểm tra hosts.deny và hosts.allow, nhưng máy mục tiêu của tôi không có các tệp như vậy.

Sau khi khởi động lại (theo đề nghị của Karthik), sshd không chạy. Tôi đã thử tự khởi động sshd trên mục tiêu:

# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f

Tôi đã thay thế /usr/lib/libssl.a bằng phiên bản gốc và bắt đầu sshd và mọi thứ đã trở lại bình thường. Vấn đề là trong trường hợp của tôi gây ra bởi một phiên bản không chính xác trong gói ban đầu tôi đã giải nén để root.


3

Tôi đã nhận được cùng một lỗi (nhưng từ bất kỳ máy nào, bao gồm cả máy rắc rối thông qua ssh localhost).

Nó bắt đầu khi tôi di chuyển một hồ sơ người dùng; tức là sau khi sao chép tập tin dưới dạng root, sau đó thực hiện các lệnh nhưchown -R username /Users/username/Destop

dù sao, hoàn toàn không chắc chắn tại sao / var / chủ sở hữu trống đã được thay đổi thành tên người dùng, nhưng sshchắc chắn cần /var/emptyphải được sở hữu bởi root (nếu không bạn nhận được ssh_exchange_identification: read: Connection reset by peer):

    sudo chown root /var/empty

Cảm ơn! Thay đổi chủ sở hữu của /var/emptyvấn đề cố định cho tôi.
Yevhen Pavliuk

1

Đây không phải là vấn đề với máy cục bộ của bạn, mà là vấn đề ở phía máy chủ. Có thể có nhiều yếu tố gây ra vấn đề này:

  1. Thay đổi cấu hình /etc/hosts.allow hoặc /etc/hosts.deny trên máy chủ từ xa.
  2. Tải máy chủ nặng.

Trước đây, khi tôi gặp những vấn đề này, tôi đã thực hiện một trong hai điều sau, theo thứ tự sau:

  1. Sửa đổi /etc/hosts.allow như được tham chiếu trong bài viết trên. (và khởi động lại máy chủ SSH)
  2. Nếu /etc/hosts.allow đã được yêu cầu, hãy khởi động lại máy chủ SSH (và cẩn thận khi bạn làm việc này!)
  3. Nếu quá trình khởi động lại không hoạt động, hãy tạo lại các khóa máy chủ và khởi động lại máy chủ SSH (điều này rất rủi ro, vì mọi người dùng đăng nhập vào máy này sẽ gặp lỗi về việc máy chủ bị thay đổi khóa)

Thường xuyên hơn không, 1 giải quyết vấn đề, nhưng tôi đã phải làm 2 trong một số trường hợp .. Tôi không thể hiểu tại sao lại như vậy, chỉ có điều nó đã hoạt động. Có lẽ nó có liên quan đến cách trình bày chìa khóa, hoặc có lẽ nó bị hỏng theo một cách nào đó - tôi không chắc chắn. Nhưng những gì tôi biết là lỗi hoàn toàn xảy ra với máy chủ và cách bắt tay xảy ra khi kết nối SSH đang được đặt.


1

Tôi đã thiết lập SSH với Cygwin và trong trường hợp của tôi, đó là tường lửa Windows gây ra chính xác lỗi này, vì vậy hãy đảm bảo cho phép kết nối với cổng 22.


0

Tôi quản lý để giải quyết vấn đề này bản thân mình thực sự dễ dàng.

Trong OS X bình thường, bạn có thể giải quyết vấn đề này bằng cách đơn giản là bật "Đăng nhập từ xa" trong Tùy chọn / chia sẻ hệ thống.

Tuy nhiên, nếu đó là máy chủ không đầu (như trong trường hợp của tôi), bạn có thể sử dụng ứng dụng Máy chủ OSX để truy cập (tên máy chủ) / Cài đặt và bật lại "Bật và tắt kết nối vỏ an toàn"


1
Tôi cũng lưu ý rằng làm thế nào bạn có thể giải quyết vấn đề, nhưng nó không khắc phục được: vô hiệu hóa đăng nhập từ xa ảnh hưởng nghiêm trọng đến hệ thống và phải chuyển đăng nhập từ xa mỗi khi bạn muốn ssh đến một địa điểm cụ thể không phải là giải pháp khả thi .
Ant6n

Vâng, đây vẫn là một vấn đề khủng khiếp mà tôi có. Tôi vừa mới tạo một kịch bản cron gốc để khởi động lại dịch vụ vào mỗi nửa đêm.
Còi báo

0

Nếu bạn đang sử dụng khóa riêng hoặc khóa bảo mật để đăng nhập vào máy chủ của mình thì bạn cần thay đổi quyền cho tệp khóa thành 660, sử dụng lệnh

sudo chmod 660 File_Name


1
(1) Mặc dù điều này có thể là nguyên nhân của sshviệc không hoạt động, nhưng không rõ vấn đề này sẽ ngẫu nhiên gây ra một hệ thống làm việc như thế nào. (2) Câu trả lời này, chẳng hạn như, sẽ hữu ích hơn nếu bạn xác định tệp bạn đang nói hoặc cung cấp hướng dẫn để cho phép người dùng xác định tệp. (3) Tôi đoán bạn đang nói về một tập tin trong (dưới) thư mục chính của người dùng. Nếu đó là trường hợp, sudokhông cần thiết.
Scott
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.