Невозможно SSH: debug1: ожидается SSH2_MSG_KEX_DH_GEX_REPLY

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

SSH работает на стандартном (22) порту.

Я разместил свой pubkey в файле /.ssh/authorized_keys

Самое интересное, что ВЧЕРА это работало великолепно!

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

ssh -vvvv servername

застрял на

debug1: ожидается SSH2_MSG_KEX_DH_GEX_REPLY

Я проверил мой pubkey, и он там! (как я проверил ?? я попросил другого парня проверить)

и затем я использовал другой компьютер (windows 7 + putty) и установил свой новый pubkey. И что? Я смог войти! И это еще один компьютер с 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

Точно такая же проблема здесь для доступа к выделенному серверу в центре данных online.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 должна быть доступна где-то в вашем предпочтительном файле конфигурации дистрибутива)

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

Другим обходным решением может быть использование следующих правил iptables для управления фрагментацией:

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

# / sbin / ip6tables -I OUTPUT -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. Это также работает, если вы указываете шифр в командной строке (например: ssh -c username @ hostname)

Совет от здесь:

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 / authorized_keys, оно должно быть 600

• проверьте включение / var / log / secure, / var / log / messages или / var / log / auth