Неможливо SSH: debug1: очікує SSH2_MSG_KEX_DH_GEX_REPLY

У нас є сервер XXX ON Amazon EC2.

SSH працює на стандартному (22) порту.

Я розмістив свій паскі у файлі /.ssh/authorized_keys

Найцікавіше, що в РІЧНИЙ день він працював чудово!

Але сьогодні я не знаю, що сталося! Я просто не можу увійти.

ssh -vvvv ім'я сервера

застряг

debug1: очікує SSH2_MSG_KEX_DH_GEX_REPLY

Я перевірив свій лобзик, і він є! (як я перевірив ?? я попросив іншого хлопця перевірити)

а потім я застосував інший комп’ютер (windows 7 + шпаклівка) і розмістив свій новий паскі. І що? Я зміг увійти! І це ще один комп’ютер з Win7 - це та сама локальна мережа, яка передбачає, що зовнішній IP той самий.

Мій приватний ключ працює для інших серверів, але не з цим.

Будь ласка, допоможіть!

Змініть мережевий інтерфейс MTU, щоб вирішити його. Це помилка для ubuntu 14.04.

Це працювало для мене:

sudo ip li set mtu 1200 dev wlan0

АБО

sudo ifconfig wlan0 mtu 1200

ssh не вдається підключитися до хоста VPN - зависає при "очікуванні SSH2_MSG_KEX_ECDH_REPLY"

Тут є і точна проблема доступу до виділеного сервера в центрі даних.net.

Після перезавантаження не виникає проблем, не потрібно змінювати MTU, ssh-з'єднання працює протягом 1-3 тижнів, потім з'являється ця сама помилка, блокуючи KEXINIT, більше неможливо підключити ssh-сервер.

Це може бути якась помилка sshd, але її обов'язково спрацьовують деякі новинки, що трапляються через 1-3 тижні, я повторював цю точну проблему багато разів із багатьма різними серверами в цій мережі, деякі кажуть, що це може бути пов'язано з помилкою cisco, можливо, пов'язане з деякими опціями DPI.

Ця проблема ніколи не траплялася з іншими серверами, якими я керую в інших центрах обробки даних, і мають точно таку ж версію distro, config та sshd.

якщо ви не хочете перезавантажувати кожні 10 днів, оскільки міжмережеві стіни центру обробки даних (або інші налаштування мережі) роблять дивні речі:

спочатку підключіться до одного з цих клієнтових обхідних шляхів:

обхід 1, знизивши місцевий MTU на стороні клієнта:

ip li set mtu 1400 dev wlan0

(1400 повинно вистачити, але ви можете спробувати використовувати менші значення, якщо потрібно)

вирішення проблеми 2 із зазначенням вибраного коду для з'єднання ssh:

ssh -c aes256-gcm@openssh.com host

(або спробуйте будь-який інший доступний цифер)

Обидва ці способи вирішення проблеми клієнта зробили це для мене, я міг підключитись і зберегти час роботи; але ви хочете виправити цю сторону сервера назавжди, тому вам не доведеться просити кожного клієнта локально налаштувати свій MTU.

На gentoo я щойно додав:

mtu_eth0="1400"

в /etc/conf.d/net

(той самий варіант mtu повинен бути доступний десь у вашому бажаному файлі конфігурації мережі distro)

Я встановив mtu на 1400, але 1460, мабуть, достатньо в більшості випадків.

Іншим допоміжним рішенням може бути використання таких правил iptables для управління фрагментацією:

# / sbin / iptables -I OUTPUT -p tcp --tcp-прапори SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

# / sbin / ip6tables -I OUTPUT -p tcp --tcp-прапори 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. Він також працює, якщо в командному рядку вказати цифер (наприклад: ssh -c ім'я користувача @ ім'я хоста)

Порада звідси:

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

Я почав мати цю проблему сьогодні, в Windows (ssh поширюється разом з Git) та Ubuntu.

Схоже, це помилка на OpenSSH, на LauchPad є проблема .

Він працював для мене в Windows, примушуючи шифр 3des-cbc і ключ на Ubuntu.

Зміна KexAlgorithm працювала на мене, і це може бути варіант, коли ви не маєте системних прав змінювати налаштування MTU. Це також може бути адресою команди екіпажу OpenSSH. напр

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

ми вирішили це, коментуючи рядок Ciphers на / etc / ssh / ssh_config

Здається, що діалогове вікно параметрів спричиняє проблему, тому що я змінив порядок, в якому Putty узгоджує обмін ключами та вирішує проблему.

cmiiw

• перевірте дозвіл ~ / .ssh / pooblasti_keys, він повинен бути 600

• перевірте ввімкнено / var / log / secure, / var / log / messages або / var / log / auth