У нас есть сервер XXX НА Amazon EC2.
SSH работает на стандартном (22) порте.
Я разместил свой pubkey в файле /.ssh/authorized_keys
Самое интересное, что ВЧЕРА все работало отлично!
Но сегодня я не знаю, что случилось! Я просто не могу войти.
ssh -vvvv имя сервера
застрял на
debug1: ожидание SSH2_MSG_KEX_DH_GEX_REPLY
Я проверил свой pubkey, и он там! (как я проверял? Я попросил другого парня проверить)
а затем я использовал другой компьютер (Windows 7 + замазка) и поместил свой новый 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.
Эта проблема никогда не возникала с другими серверами, которыми я управляю в других центрах обработки данных, и которые имеют точно такой же дистрибутив, конфигурацию и версию 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
https://stackoverflow.com/questions/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
В моем случае у меня нет разрешения на уменьшение размера 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