SSH를 사용할 수 없음 : debug1 : SSH2_MSG_KEX_DH_GEX_REPLY 예상

Amazon EC2에 서버 XXX가 있습니다.

SSH가 표준 (22) 포트에서 실행 중입니다.

pubkey를 /.ssh/authorized_keys 파일에 넣었습니다.

재미있는 것은 어제 그것이 잘 작동했다는 것입니다!

그러나 오늘, 나는 무슨 일이 있었는지 모른다! 그냥 로그인 할 수 없습니다.

ssh -vvvv 서버 이름

붙어있다

debug1 : SSH2_MSG_KEX_DH_GEX_REPLY 예상

나는 나의 pubkey를 점검했다. (내가 확인한 방법 ?? 다른 사람에게 확인을 요청했다)

그런 다음 다른 컴퓨터 (Windows 7 + 퍼티)를 사용하여 새 pubkey를 배치했습니다. 그리고 뭐? 로그인 할 수있었습니다! 그리고 Win7이 설치된 다른 컴퓨터는 외부 IP가 동일하다는 것을 나타내는 동일한 LAN에 있습니다.

내 개인 키는 다른 서버에서는 작동하지만 이것과는 작동하지 않습니다.

도와주세요!

네트워크 인터페이스 MTU를 변경하여 해결하십시오. 이것은 우분투 14.04의 버그입니다.

이것은 나를 위해 일했다 :

sudo ip li set mtu 1200 dev wlan0

또는

sudo ifconfig wlan0 mtu 1200

ssh가 VPN 호스트에 연결하지 못합니다- 'SSH2_MSG_KEX_ECDH_REPLY가 예상됩니다'

online.net 데이터 센터의 전용 서버에 액세스하는 것과 동일한 정확한 문제가 있습니다.

재부팅 후 문제가 없으며 MTU를 변경할 필요가 없으며 ssh 연결은 1 ~ 3 주 동안 작동 한 다음 KEXINIT를 차단하는 똑같은 버그가 나타나고 더 이상 ssh 서버에 연결할 수 없습니다.

그것은 일종의 sshd 버그 일 수 있지만 반드시 1 ~ 3 주 후에 발생하는 일부 nework로 인해 발생합니다.이 네트워크의 많은 다른 서버 에서이 정확한 문제를 여러 번 재현했습니다. 일부 DPI 옵션과 관련이있을 수 있습니다.

이 문제는 다른 데이터 센터에서 관리하는 다른 서버에서는 발생하지 않았으며 정확히 동일한 배포, 구성 및 sshd 버전이 있습니다.

데이터 센터 방화벽 (또는 다른 네트워크 조정)이 이상한 일을하고 있기 때문에 10 일마다 재부팅하지 않으려는 경우 :

먼저 해당 클라이언트 측 해결 방법 중 하나와 연결하십시오.

해결 방법 1, 로컬 클라이언트 측 MTU 낮추기 :

ip li set mtu 1400 dev wlan0

(1400이면 충분하지만 필요한 경우 더 낮은 값을 사용하려고 할 수 있습니다)

해결 방법 2, ssh 연결을 위해 선택한 사이퍼를 지정합니다.

ssh -c aes256-gcm@openssh.com host

(또는 다른 사용 가능한 사이퍼로 시도하십시오)

이 두 가지 클라이언트 측 해결 방법으로 인해 문제가 해결되었습니다. 가동 시간을 연결하고 절약 할 수있었습니다. 그러나이 서버 측을 영원히 고치려고하므로 모든 클라이언트에게 로컬로 MTU를 조정하도록 요구하지 않아도됩니다.

젠투에서 방금 추가했습니다.

mtu_eth0="1400"

/etc/conf.d/net에

(선호하는 배포 네트워크 구성 파일 어딘가에 동일한 mtu 옵션을 사용할 수 있어야합니다)

나는 mtu를 1400으로 설정했지만 대부분의 경우 1460으로 충분합니다.

또 다른 도움이되는 해결책은 다음 iptables 규칙을 사용하여 조각화를 관리하는 것입니다.

# / sbin / iptables -I 출력 -p tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

# / sbin / ip6tables -I 출력 -p tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

(그러나 나는 지금 까지이 것을 필요로하지 않았다)

또한이 문제의 증상은 다음과 같습니다.

debug1: SSH2_MSG_KEXINIT sent

뿐만 아니라

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

행진 편집 2016 :

• 서버에서 mtu를 1400으로 낮추는 것이 가장 효과적이지만 최근에는 서버에서 mtu가 이미 1400으로 낮추어 문제가 다시 나타 났으며 클라이언트도 mtu를 1400으로 낮추어야했습니다.

• "서버가 연결을 재설정했습니다"라고 말할 때까지 페이지가 다시로드되기를 기다리는 웹 로그인 양식에도 문제가 나타 났으며 클라이언트가 mtU를 1400으로 설정 한 후에도 해결되었습니다.

  관련된 링크들 :

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085

http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

https://nowhere.dk/articles/natty-narwhal-problems-connecting-to-servers-behind-cisco-firewalls-using-ssh

/programming/2419412/ssh-connection-stop-at-debug1-ssh2-msg-kexinit-sent

http://www.1-script.com/forums/ssh/ssh-hang-after-ssh2-msg-kexinit-sent-10616-.htm

http://www.snailbook.com/faq/mtu-mismatch.auto.html

제 경우에는 MTU 크기를 줄일 권한이 없습니다. 암호를 수동으로 지정해도 작동하지 않습니다.

MAC 목록을 단축 한 후 연결할 수 있습니다. 예 :

ssh -o MACs=hmac-sha2-256 <HOST>

Ubuntu 클라이언트 시스템을 업그레이드 한 후에도 같은 문제가 발생했습니다. / etc / ssh / ssh_config에서 "Ciphers"행의 크기를 줄임으로써 문제를 해결했습니다. 명령 행에서 사이퍼를 지정하는 경우에도 작동합니다 (예 : ssh -c username @ hostname).

여기에서 팁 :

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39

오늘 Windows (Git과 함께 배포 된 SSH)와 Ubuntu 에서이 문제를 시작했습니다.

OpenSSH에 버그가있는 것 같습니다 . LauchPad에 문제가 있습니다 .

Windows에서 3des-cbc 암호와 Ubuntu의 키를 강요했습니다.

KexAlgorithm을 변경하면 나에게 도움이되었으며 MTU 설정을 변경할 수있는 시스템 권한이없는 옵션 일 수 있습니다. 이것은 OpenSSH 승무원이 해결해야 할 것일 수도 있습니다. 예 :

ssh -o KexAlgorithms=ecdh-sha2-nistp521 fu@bar.com

/ etc / ssh / ssh_config에서 Ciphers 라인을 주석 처리하여 해결했습니다.

퍼티가 키 교환을 협상하고 문제가 해결되는 순서를 변경했기 때문에 옵션 대화 상자가 문제를 일으키는 것은 분명합니다.

cmiiw

• ~ / .ssh / authorized_keys 권한을 확인하십시오. 600이어야합니다.

• / var / log / secure, / var / log / messages 또는 / var / log / auth를 확인하십시오.