Вопрос или проблема
Я изменил номер порта ssh с 22 на 2222.
Предыдущее соединение с дефолтным портом ssh 22 работает нормально.
Я правильно настроил NAT на маршрутизаторе.
Когда я пытаюсь отладить это
ssh -v -p2222 www.example.com
Я получаю эту ошибку и зависаю
debug1: SSH2_MSG_KEXINIT
Ниже приведен весь лог отладки
bob@server:~$ ssh -v -p2222 www.example.com
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: Применение параметров для *
debug1: Подключение к www.example.com [100.100.100.100] порт 2222.
debug1: Соединение установлено.
debug1: файл идентификации /home/bob/.ssh/identity тип -1
debug1: файл идентификации /home/bob/.ssh/id_rsa тип -1
debug1: файл идентификации /home/bob/.ssh/id_dsa тип -1
debug1: Удаленная версия протокола 2.0, удаленная версия ПО OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: совпадение: OpenSSH_4.7p1 Debian-8ubuntu1.2 паттерн OpenSSH*
debug1: Включение режим совместимости для протокола 2.0
debug1: Локальная строка версии SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: SSH2_MSG_KEXINIT отправлено
Соединение закрыто 100.100.100.100
Вот так соединение просто закрывается.
Я использовал gnome-terminal, putty, securecrt на нескольких машинах внутри и вне сети,
все равно получаю одну и ту же ошибку.
У меня только что произошла такая проблема на хосте XEN. Я продублировал этот хост с другого, и как это бывает, я удалил ключи хоста в /etc/ssh после этого, думая, что позже будут сгенерированы новые. Но этого никогда не произошло, и sshd радостно запустилась без ключей хоста. При попытке подключиться к этому хосту он отключался после SSH2_MSG_KEXINIT. Все, что мне пришлось сделать, это создать ключи хоста, что на машине на базе Debian делается следующим образом:
dpkg-reconfigure openssh-server
У меня была эта проблема, и я решил ее, установив MTU на целевом маршрутизаторе / брандмауэре и на целевом хосте таким же, как на исходном хосте (1500).
SSH2_MSG_KEXINIT – это не ошибка. Это просто говорит вам о том, что начинает процесс обмена ключами ssh.
Если другая сторона закрывает соединение в этот момент, похоже, ей по какой-то причине не нравится ваше соединение 🙂 логи с удаленной стороны могут содержать информацию о том, почему соединение закрывается внезапно. (например, tcpwrappers)
У меня была такая же проблема, sshd запутался, когда я изменил порт в sshd_config и перезапустил службу sshd, когда я наконец посмотрел логи сервера (которые, похоже, вы не можете), sshd жаловалась, что порт уже занят, netstat согласился, а команда ps показала несколько экземпляров служб sshd, работающих одновременно. Я убил их и снова запустил sshd, и смог подключиться. Черт возьми, я пытался перезагрузить, чтобы исправить проблему, но, похоже, это не помогло, потому что это, вероятно, решение проблемы.
Кратко говоря, sshd, который должен прослушивать порт 2222 для аутентификации, не тот, который на самом деле прослушивает, а другой процесс sshd.
Я столкнулся с подобной проблемой (сброс соединения после SSH2_MSG_KEXINIT) при подключении через ssh к контейнеру, размещенному в кластере kubernetes. Решение в моем случае заключалось в добавлении возможностей контекста безопасности: SYS_CHROOT, AUDIT_CONTROL, AUDIT_WRITE. SYS_CHROOT устранил сброс соединения. AUDIT_CONTROL и AUDIT_WRITE были необходимы для устранения ошибок, которые проявились после решения проблемы со сбросом соединения.
Ответ или решение
Проблема, с которой вы столкнулись, связана с завершением соединения SSH на этапе отправки сообщения "SSH2_MSG_KEXINIT". Давайте рассмотрим это более детально и предложим возможные решения.
Причины возникшей проблемы
1. Сообщение SSH2_MSG_KEXINIT:
Это сообщение не является ошибкой. Оно указывает на начало процесса обмена ключами SSH между клиентом и сервером. Если соединение закрывается сразу после этого сообщения, это может указывать на проблемы на стороне сервера или сетевой конфигурации.
2. Изменение порта SSH:
Вы упомянули, что изменили порт SSH с 22 на 2222. Важно убедиться, что:
- На сервере SSH-сервер действительно слушает на новом порту. Вы можете это проверить с помощью команды
netstat -tuln | grep 2222на сервере. - Служба SSH была перезапущена после изменения конфигурации. Используйте команду
sudo systemctl restart sshилиsudo service ssh restart, в зависимости от вашей операционной системы.
3. Отсутствие хост-ключей:
Как показывает опыт, иногда, если хост-ключи SSH отсутствуют, это может привести к неожиданному поведению. Если вы перенесли виртуальную машину или клонировали её, то хост-ключи могут не были созданы. В таком случае вам нужно сгенерировать новые ключи через команду:
sudo dpkg-reconfigure openssh-serverПосле этого перезапустите SSH-сервер.
4. Проблемы с NAT и Firewall:
Убедитесь, что NAT на роутере правильно настроен на перенаправление порта 2222 на ваш сервер. Кроме того, проверьте настройки файрвола (iptables или ufw) на сервере, чтобы убедиться, что порт 2222 открыт для входящих соединений:
sudo ufw allow 2222/tcp5. Конфликт служб SSH:
Если на сервере запущено несколько экземпляров sshd, это может привести к конфликтам. Используйте команду:
ps aux | grep sshdЧтобы проверить, сколько процессов sshd запущено. Убедитесь, что только один экземпляр работает на нужном порту. Если есть лишние процессы, остановите их командой sudo kill <PID>.
6. Проблемы с MTU:
Иногда параметры MTU (Maximum Transmission Unit) в маршрутизаторе или на сервере могут вызывать проблемы с соединением. Убедитесь, что MTU на всех устройствах (как на ваших, так и на сервере) совпадает. Как правило, значение 1500 является стандартным.
Рекомендации
- Проверьте логи SSH на сервере. Они находятся по пути
/var/log/auth.logили/var/log/secure, в зависимости от вашей конфигурации. Логи могут содержать сообщения об ошибках, которые помогут диагностировать проблему. - Используйте другие клиенты для SSH, такие как PuTTY или SecureCRT, чтобы убедиться, что проблема не связана с конкретным клиентом.
- Если ваша инфраструктура поддерживает, можно даже рассмотреть возможность использования встроенного мониторинга для получения более подробных метрик и состояния подключения.
Заключение
Проблемы с SSH могут быть вызваны множеством факторов, включая отсутствие хост-ключей, неправильные настройки порта, проблемы с NAT и MTU, а также конфликты служб. Постепенная проверка и устранение каждой из этих возможных проблем, начиная с логов сервера и завершения проверкой конфигурации сети, должны помочь в решении вашей проблемы с SSH-соединением.