SSH 연결이 실패할 때 Dispatch_protocol_error: type 51 seq 5가 무엇을 의미하며 어떻게 해결합니까?

SSH 연결이 실패할 때 Dispatch_protocol_error: type 51 seq 5가 무엇을 의미하며 어떻게 해결합니까?

다음 명령을 사용하여 SSH를 통해 Linux 서버에 연결하려고 합니다.

ssh [email protected] -p 22

그러나 연결할 수 없습니다. 이라는 메시지만 있었습니다 dispatch_protocol_error: type 51 seq 5. ssh 명령은 다음 메시지와 함께 닫힐 때까지 약 1~2분 동안 중단됩니다.

Connection to ip.of.server.com closed by remote host.
Connection to ip.of.server.com closed.

Google에서 dispatch_protocol_error 메시지를 검색해도 이 특정 디스패치 프로토콜 오류와 관련된 어떤 결과도 나오지 않았습니다. 대부분 사람들은 다른 디스패치 프로토콜 오류(type 및 seq에 대한 다른 값 사용)에 대해 질문했으며 이들 중 어느 것도 이것이 무엇인지에 대한 설명이 없었습니다. 오류 메시지는 다음을 의미합니다.

다소 흥미로운 점은이 OpenSSH FAQ여기서 질문 중 하나는 "이전 버전의 OpenSSH가 세션 키 재설정을 지원하지 않았기 때문에" 발생하는 "디스패치 프로토콜 오류: 유형 20"에 관한 것입니다. RekeyIntervalSeconds 0"SSH 2.3의 ssh2_config 또는 sshd2_config"에 추가하라고 제안합니다 . 무슨 일이 일어나는지 확인하기 위해 이를 내 (클라이언트) ssh_config에 추가하려고 시도했지만(ssh2_config 파일이 없음) 도움이 되지 않았습니다(사실 "잘못된 구성 옵션"이었습니다).

포트( ) 없이 연결을 시도했는데 결과는 같았습니다. 나도 노력했다ssh [email protected]알려진 호스트 목록에서 호스트를 제거합니다.를 사용하여 ssh-keygen -R hostname현재 RSA 키 지문에 문제가 있다고 가정합니다. 그러나 이로 인해 연결할 수 없었고 동일한 오류 메시지가 표시되었습니다.

저는 Ubuntu 16.04를 사용하고 있으며 서버는 CentOS 6.8입니다. 내 (클라이언트) SSH 버전은 7.2 버전입니다.이 답변: ssh -v localhost):

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g

내 추측과 내 상사도 이에 동의합니다. 이는 서버의 문제이므로 컴퓨터에서 작업하는 것만으로는 문제를 해결할 수 없습니다.

그래서 제 질문은,이 오류 메시지의 의미와 해결 방법?

Ps: 저는 SSH 전문가가 아니기 때문에 아마도 매우 어리석은 행동을 했고 이 문제를 해결하는 데 필수적인 것을 놓쳤을 것입니다.

편집하다:-v(verbose) 옵션을 사용하여 ssh를 실행합니다. 이에 따르면 ( debug1: Authentication succeeded (none).)에 접속하여 인증할 수 있었습니다. 이 메시지 뒤에는 내 오류를 포함하여 다음과 같은 메시지가 있습니다. 전체 로그는 다음과 같습니다.

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ip.of.server.com [ip.of.server.com] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to ip.of.server.com:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: [email protected] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [email protected] compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:server_host_key_ssh_rsa_is_here
debug1: Host 'ip.of.server.com' is known and matches the RSA host key.
debug1: Found key in /home/myuser/.ssh/known_hosts:6
debug1: rekey after 3249842342 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 3249842342 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentication succeeded (none).
Authenticated to ip.of.server.com ([ip.of.server.com]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
dispatch_protocol_error: type 51 seq 5
debug1: Received SSH2_MSG_UNIMPLEMENTED for 6
debug1: Received SSH2_MSG_UNIMPLEMENTED for 7
debug1: Received SSH2_MSG_UNIMPLEMENTED for 9
debug1: Received SSH2_MSG_UNIMPLEMENTED for 10
debug1: Received SSH2_MSG_UNIMPLEMENTED for 11
debug1: Received SSH2_MSG_UNIMPLEMENTED for 12

... (there are lots of this SSH2_MSG_UNIMPLEMENTED message)

debug1: Received SSH2_MSG_UNIMPLEMENTED for 60
debug1: Received SSH2_MSG_UNIMPLEMENTED for 61
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 1 clearing O_NONBLOCK
debug1: channel 0: free: client-session, nchannels 1
Connection to ip.of.server.com closed by remote host.
Connection to ip.of.server.com closed.
Transferred: sent ..., received ... bytes, in ... seconds
Bytes per second: sent ..., received ...
debug1: Exit status -1

서버 측 정보: CentOS에 대한 sshd 로그 보기( /var/log/secure, as이 답변보여줍니다), 관련된 유일한 결과는 유사한 오류의 반복입니다.

Jan  5 14:38:44 myserverside sshd[1234]: dispatch_protocol_error: type 90 seq 6
Jan  5 14:38:44 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 7
Jan  5 14:38:46 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 9
Jan  5 14:38:48 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 10
Jan  5 14:38:50 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 11
Jan  5 14:38:52 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 12

...

Jan  5 14:40:31 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 60
Jan  5 14:40:33 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 61

이 항목 전후의 다른 항목(다른 ID 포함)은 이 특정 시도에서 나온 것이 아닙니다(시간 데이터에서 볼 수 있듯이 성공적인 PuTTY 연결에서 나온 것입니다). 이 오류 메시지의 숫자는 클라이언트 측에서 얻은 숫자와 동일하다는 점에 유의해야 합니다.

-M 플래그( )를 사용해도 동일한 오류가 발생했습니다.ssh -M [email protected]

이상하게도 이전 버전의 Ubuntu(Ubuntu 12.04)가 설치된 클라이언트를 사용하면 연결할 수 있었습니다. 따라서 버전 비호환성(서버가 너무 오래되었거나 클라이언트가 너무 새 버전)일 수 있습니다. 약 한 달 전에 Ubuntu 16.04 컴퓨터를 사용하여 연결할 수 있었기 때문에 SSH의 최근 업데이트일 수도 있습니다. 구성 문제.

Ps: PuTTY(Ubuntu 버전)를 통해 성공적으로 연결할 수 있었습니다. 따라서 문제는 SSH를 통해 연결을 시도할 때만 발생했습니다.

관련 정보