ssh застрял в ожидании SSH2_MSG_KEX_ECDH_REPLY

Я столкнулся с этой проблемой на сервере в другой стране. Я изменил mtu на значения от 1200 до 1500, но ничего не изменилось. Я переустановил openssh, но ничего не произошло. Пожалуйста, помогите. Спасибо. Кроме того, принуждение 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 (разовый вариант):
На командной строке при выполнении команды подключения SSH добавьте параметр -o KexAlgorithms=ecdh-sha2-nistp521

Вариант 2 (окончательный):
Добавьте KexAlgorithms=ecdh-sha2-nistp521 в соответствующий файл ssh_config

После добавления настроек ниже SSH начал работать

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

У меня была та же проблема, и в моем случае проблема заключалась в том, что ssh-сервер находился за балансировщиком нагрузки F5.
Подключения напрямую к серверу работали нормально, но не через балансировщик нагрузки.

Решение заключалось в том, чтобы удалить профиль http, который был непреднамеренно назначен на VIP.

Я и служба ИТ-поддержки моего работодателя потратили несколько часов на попытки решить эту проблему, которая возникала только при подключении через VPN. Ни алгоритмы, ни решения, связанные с MTU, опубликованные здесь и в других местах, не помогли.

В этом случае файл настроек OpenVPN пришлось модифицировать, чтобы отключить сжатие с помощью директивы comp-lzo no в файле (можно также использовать в командной строке). Хотя это может быть связано с проблемой MTU, это был единственный способ, который мы нашли для ее устранения.

Надеюсь, это поможет другим, кто столкнется с этой трудной для диагностики проблемой.

При плохих интернет-соединениях/горячих точках это может происходить. Вы можете решить эту проблему, ограничив соединение до более низкой скорости передачи байт/секунду. Мне приходилось это делать для передачи файлов и для базовых соединений, когда я использовал свои мобильные точки доступа или гостевые сети, и это работало каждый раз.

Другие ответы о том, как изменить KexAlgorithms, были для меня ненадежными – если только сервер SSH не устарел, тогда да.

Согласно этому другому ответу от @Kamil Maciorowski, вы можете ограничить соединение SSH, добавив этот переключатель:

-o ProxyCommand='pv -qL 1K | nc %h %p | pv -qL 1K'

Ваша вся команда будет выглядеть примерно так:

ssh -o ProxyCommand='pv -qL 1K | nc %h %p | pv -qL 1K' USERNAME@IP_ADDRESS

Я сейчас выполняю эту команду на точке доступа, и 1K байт/секунду близко к максимальному значению, которое я могу достичь – что вполне нормально для SSH. Не стесняйтесь изменять 1K на максимально возможное значение.

Добавлю заметки Камила Мачоровски ниже:

Заметки:

• С помощью этого метода вы ограничиваете все соединение SSH, все, что проходит через него, все туннели, X11 пересылку, другие сессии (в случае совместного использования соединения), все. Вы ограничиваете сырое TCP-соединение.

• Если вы используете ssh -N, то вы можете захотеть, чтобы pvs не были тихими и фактически сообщали о пропускной способности туннелей:

    ssh -o ProxyCommand='pv -cN out -L 20K | nc %h %p | pv -cN in -L 10K' -ND 8080 user@server
  

• С помощью pv -R (вызванного отдельно) вы можете изменить настройки работающего pv, таким образом вы можете подстраивать ограничение в любое время. Если вы хотите это сделать, то pv -P внутри ProxyCommand будет полезен, чтобы знать, какому PID принадлежит какой pv. См. man 1 pv для подробностей.

• Если ваша конфигурация уже использует ProxyCommand, то вам нужно обернуть существующее значение (вместо nc %h %p) в pvs. Если ваша конфигурация уже использует ProxyJump, тогда вам нужно перевести это в ProxyCommand, а затем обернуть в pvs.