SSH는 SSH2_MSG_KEX_ECDH_REPLY를 기다리는 상태로 유지됩니다.

SSH는 SSH2_MSG_KEX_ECDH_REPLY를 기다리는 상태로 유지됩니다.

다른 나라의 서버에서 이 문제가 발생했습니다. mtu를 1200에서 1500 사이의 값으로 변경했지만 아무 것도 변경되지 않았습니다. openssh를 다시 설치했지만 아무 일도 일어나지 않았습니다. 도와주세요. tnx.HostKeyAlgorithms를 하나의 알고리즘으로 강제하는 것도 도움이 되지 않습니다. 또한 서버에서 ssh를 테스트했는데 제대로 작동합니다. 문제가 네트워크 매개변수와 관련된 것 같은데 어떤 매개변수를 변경해야 하는지 모르겠습니다.

debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: [email protected] MAC: <implicit                                                                                                                                                             > compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit                                                                                                                                                             > compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

답변1

나는 똑같은 문제가 있었고 다음과 같이 해결했습니다.

옵션 1(일회용): 명령줄에서 SSH 연결 명령을 제출할 때 -o KexAlgorithms=ecdh-sha2-nistp521매개변수를 추가합니다.

옵션 2(명확한): KexAlgorithms=ecdh-sha2-nistp521해당 ssh_config 파일에 추가

답변2

다음 설정을 추가한 후 SSH가 작동하기 시작했습니다.

[root@RHELSERVER .ssh]# cat /root/.ssh/config
KexAlgorithms diffie-hellman-group18-sha512

답변3

나도 같은 문제에 직면했습니다. 제 경우에는 대상 SSH 서버가 F5 로드 밸런서 뒤에 있었습니다.
서버에 직접 연결하면 제대로 작동하지만 로드 밸런서를 통해서는 작동하지 않습니다.

해결 방법은 실수로 VIP에 할당된 http 프로필을 삭제하는 것입니다.

답변4

고용주의 IT 지원 직원과 저는 이 문제를 해결하기 위해 몇 시간을 보냈습니다. 이 문제는 VPN을 통해 연결된 경우에만 발생합니다. 여기에 게시된 알고리즘 및 MTU 관련 솔루션도 없습니다.다른 곳에서도움이되었습니다.

이 경우 comp-lzo no파일의 지침을 사용하여 압축을 제거하도록 OpenVPN 설정 파일을 수정해야 합니다(명령줄에서도 사용할 수 있음). 이는 MTU 문제와 관련이 있을 수 있지만 이 문제를 해결하기 위해 찾은 유일한 솔루션입니다.

이것이 진단하기 어려운 문제에 직면한 다른 사람들에게 도움이 되기를 바랍니다.

관련 정보