SSH2_MSG_KEX_ECDH_REPLY에서 SSH가 멈춤: 항상 MTU 문제는 아니다

터널은 살아 있고 배너도 도착했는데, 클라이언트는 키 교환 응답을 기다린다는 메시지를 출력합니다. 검색 결과는 곧장 MTU를 가리키며, 때로는 그것이 맞습니다. 자주 아닙니다: 클라이언트가 키 파일을 읽지 못했거나 양쪽이 알고리즘에 합의하지 못해서 응답이 아예 전송되지 않았을 수 있습니다. 이 줄은 클라이언트가 무엇을 기다리는지를 설명할 뿐, 기다림이 시작된 이유를 말하지 않습니다. 증상으로 보고 어떤 크기도 바꾸기 전에 세 가지 원인을 분리하세요.

응답이 애초에 기대되었는지 보려면 추적을 읽으세요

자세한 출력은 침묵 직전의 마지막 성공 단계를 보여 줍니다. 서버의 프로토콜 배너가 도착했다면 TCP가 작동하고 원격 끝이 살아 있으며, 남은 질문은 특정 패킷 하나에 무슨 일이 있었는가입니다. 배너 뒤의 일 분 침묵은 경로 문제처럼 보입니다. 일치하는 키 교환 방법이 없다는 메시지는 정책 문제입니다. 서버가 세션을 닫으며 긴 기다림이 끝난다면 서버가 포기한 것이고, 서버 로그가 이유를 설명합니다.

마지막 경우에는 클라이언트를 건드리기 전에 서버의 인증 로그를 읽으세요. 서버가 보내지 않은 결정을 클라이언트는 볼 수 없습니다.

작은 응답이 여전히 너무 클 수 있는 이유

키 교환 응답은 보통 아주 작아서 크기를 탓하는 것은 이상하게 들립니다. 호스트 인증서가 있으면 서버의 인증서 체인을 실어 나르기 때문에 응답은 작지 않습니다. 그래서 세션에서 터널의 사용 가능한 페이로드를 넘을 수 있는 첫 패킷이 됩니다. 경로 MTU 탐색 피드백이 경로 어딘가에서 유실되면, 송신자는 들어가지 않는 패킷을 계속 재전송하고 클라이언트는 같은 줄에서 영원히 기다립니다.

크기를 가정하지 말고 확인하세요. ip link show tun0로 터널의 MTU를 읽고, 단편화되면 안 되는 프로브를 보냅니다: ping -4 -M do -s 1352 host를 더 작은 페이로드로 반복합니다. 특정 크기에서 실패가 성공으로 바뀌는 것은 증거이고, 균일한 실패는 ICMP가 필터링된다는 뜻일 뿐 아무것도 알려 주지 않습니다.

일시적 축소는 이론을 빠르게 확인해 주고, 영구 버전은 프로필에 두거나 터널을 전달하는 라우터의 MSS 클램프로 설정합니다:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

크기 문제를 흉내 내는 두 가지 원인

클라이언트가 읽을 수 없는 키 파일은 자세한 출력에서도 경고 없이 같은 기다림을 만듭니다. known_hosts의 한 패턴이 이를 쉽게 만듭니다: 한 계정만 읽을 수 있는 CA 공개 키를 가리키는 @cert-authority 항목입니다. 그 파일을 소유한 계정은 연결되고 다른 모든 계정은 멈춥니다. 실패가 호스트가 아니라 사용자를 따라간다면 패킷 크기보다 파일 모드를 먼저 확인하세요.

업그레이드는 양쪽이 예전에 공유하던 알고리즘을 없앨 수도 있습니다. 서버가 아직 제공하는 한 가지 방법을 진단용으로 고정하세요: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. 즉시 성공하는 연결은 경로가 정상임을 증명하며, 수정은 양쪽의 협상 정책에 속합니다.

기록해 둘 만한 세 가지 사실

변경 전후의 터널 MTU, 큰 파일 복사가 반복 가능한 크기에서 실패하는지, 같은 터널의 인증서 없는 호스트도 똑같이 멈추는지를 적어 두세요. 그 세 가지 관찰은 명령 더미보다 빠르게 크기를 권한과 협상에서 분리합니다.

그것은 또한 다음 사람이 크기와 무관했던 결함 때문에 MTU를 낮추는 것을 막아 줍니다.

그림이 여전히 불분명하면 같은 터널의 두 번째 클라이언트에서 시험하세요. 연결되는 클라이언트는 결함을 경로에서 첫 번째 컴퓨터의 설정으로 옮깁니다.