Вопрос или проблема
Я перезапустил свой сервер Fedora 25, так как не перезапускал его в течение трех дней (единственные две вещи, которые я установил, это JRE и screen) и заметил, что SSH перестал работать. Иногда соединение сбрасывается, иногда закрывается.
sh-3.2# ssh [email protected]
Соединение сброшено 192.168.1.127
Я не знаю, как просмотреть свои логи, так как теперь у меня больше нет доступа по ssh, но вот что выводится, если я использую ssh -vvv (я не уверен, выводит ли OS X El Capitan столько же, сколько Linux)
sh-3.2# ssh -vvv [email protected]
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 21: Применение параметров для *
debug1: /etc/ssh/ssh_config строка 56: Применение параметров для *
debug2: ssh_connect: needpriv 0
debug1: Подключение к 192.168.1.127 [192.168.1.127] порт 22.
debug1: Соединение установлено.
debug1: permanently_set_uid: 0/0
debug1: Включение兼容模式 для протокола 2.0
debug1: Локальная версия строки SSH-2.0-OpenSSH_6.9
debug1: Удаленная версия протокола 2.0, удаленная версия программного обеспечения OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug2: fd 3 установка O_NONBLOCK
debug1: Аутентификация на 192.168.1.127:22 как 'root'
debug3: hostkeys_foreach: чтение файла "/var/root/.ssh/known_hosts"
debug1: SSH2_MSG_KEXINIT отправлено
Соединение сброшено 192.168.1.127
sh-3.2#
Обычно я подключаюсь с помощью открытого ключа, но использование его не меняет вывод выше. Nginx продолжает работать полностью вместе с Cockpit, ничего не изменилось в сети. Если я пытаюсь подключить мой сервер к самому себе по SSH, то ничего не изменяется снова. (Я осознаю, что всегда использовать root небезопасно, но я пробовал все остальное)
[root@localhost ~]# ssh -vvvv localhost
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config строка 56: Включение файла /etc/ssh/ssh_config.d/05-red
hat.conf глубина 0
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config.d/05-redhat.conf
debug1: /etc/ssh/ssh_config.d/05-redhat.conf строка 2: include /etc/crypto-policie
s/back-ends/openssh.config совпадений не обнаружено
debug1: /etc/ssh/ssh_config.d/05-redhat.conf строка 8: Применение параметров для *
debug2: разрешение "localhost" порт 22
debug2: ssh_connect_direct: needpriv 0
debug1: Подключение к localhost [::1] порт 22.
debug1: Соединение установлено.
debug1: permanently_set_uid: 0/0
debug1: файл идентификации /root/.ssh/id_rsa тип 1
debug1: key_load_public: Файл или директория не найдены
debug1: файл идентификации /root/.ssh/id_rsa-cert тип -1
debug1: key_load_public: Файл или директория не найдены
debug1: файл идентификации /root/.ssh/id_dsa тип -1
debug1: key_load_public: Файл или директория не найдены
debug1: файл идентификации /root/.ssh/id_dsa-cert тип -1
debug1: key_load_public: Файл или директория не найдены
debug1: файл идентификации /root/.ssh/id_ecdsa тип -1
debug1: key_load_public: Файл или директория не найдены
debug1: файл идентификации /root/.ssh/id_ecdsa-cert тип -1
debug1: key_load_public: Файл или директория не найдены
debug1: файл идентификации /root/.ssh/id_ed25519 тип -1
debug1: key_load_public: Файл или директория не найдены
debug1: файл идентификации /root/.ssh/id_ed25519-cert тип -1
debug1: Включение兼容模式 для протокола 2.0
debug1: Локальная версия строки SSH-2.0-OpenSSH_7.4
debug1: Удаленная версия протокола 2.0, удаленная версия программного обеспечения OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug2: fd 3 установка O_NONBLOCK
debug1: Аутентификация на localhost:22 как 'root'
debug3: hostkeys_foreach: чтение файла "/root/.ssh/known_hosts"
debug3: отправка пакета: тип 20
debug1: SSH2_MSG_KEXINIT отправлено
Соединение сброшено по адресу ::1 порт 22
[root@localhost ~]# ^C
Также ни одно другое устройство в моей сети не может подключиться. Я не пробовал PuTTY, однако Cyberduck просто говорит мне, что “recv не удался”. Я заметил, что соединение всегда сбрасывается после отправки “SSH2_MSG_KEXINIT”, но я не знаю, что это.
Вот моя ssh конфигурация тоже, все из них закомментированы:
[root@localhost ~]# cat /etc/ssh/ssh_config
# $OpenBSD: ssh_config,v 1.30 2016/02/20 23:06:23 sobrado Exp $
# Хост *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Protocol 2
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3d
es-cbc
# MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
#
# Чтобы изменить системную конфигурацию ssh, создайте файл *.conf под
# /etc/ssh/ssh_config.d/ который будет автоматически включен ниже
Include /etc/ssh/ssh_config.d/*.conf
Я пробовал dnf переустановить openssh-server, и это не изменило ничего. Я не уверен ни в чем, но, как я уже сказал, я не знаю, как просмотреть журналы OpenSSH (вообще? Я прав в том, что у него есть журналы?) в Fedora 25. Было бы приятно, если бы это можно было исправить, так как это мешает мне работать уже 4 часа. Спасибо.
Для наглядности, ссылка в комментарии от @Jakuje решила мою проблему.
Сбросьте размер MTU на 576:
ifconfig eth0 mtu 576
Сделав это только на хосте, на котором работает ssh сервер, мне это помогло, но ссылка предлагает сделать это и на сервере, и на клиенте.
Ладно. Итак, перезапуск sshd через systemctl restart sshd
не сработал. Однако мне предложили использовать # /sbin/sshd
, чтобы запустить OpenSSH. Это, неожиданно, сработало, и все работало как до перезапуска. Я не понимаю, почему. Вероятно, проблема с правами доступа. Я не знаю точно, но ошибка “Соединение сброшено соперником” кажется одной из самых сложных для отладки.
Я столкнулся с аналогичной проблемой (сброс соединения после SSH2_MSG_KEXINIT), когда подключался по ssh к контейнеру, размещенному в кластере Kubernetes. Решением в моем случае было добавить возможности контекста безопасности: SYS_CHROOT, AUDIT_CONTROL, AUDIT_WRITE. SYS_CHROOT решил проблему со сбросом соединения. AUDIT_CONTROL и AUDIT_WRITE были необходимы для устранения ошибок, проявившихся после решения проблемы со сбросом соединения.
Ответ или решение
Ошибка "Connection reset/closed by server after SSH2_MSG_KEXINIT в SSH"
Описание проблемы
Проблема, с которой вы столкнулись, возникает при попытке установить SSH-соединение с вашим сервером Fedora 25, что приводит к ошибкам типа "Connection reset by peer" и "далее". Все это происходит после отправки сообщения SSH2_MSG_KEXINIT
. Рассмотрим детально причины и возможные решения данной проблемы.
Анализ вывода команд SSH
Из предоставленного вами вывода команды ssh -vvv
, видно, что соединение устанавливается, но сбрасывается после обмена инициализационными сообщениями (KEX). Это может указывать на несколько проблем:
-
Проблемы с MTU: Одной из частых причин подобного поведения является несоответствие настроек MTU (Maximum Transmission Unit). Если MTU настроен неправильно, это может привести к сбоям соединения. В вашем случае использование команды
ifconfig eth0 mtu 576
решило проблему. Рекомендуется также применять аналогичное значение MTU на клиентской стороне. -
Проблемы с конфигурацией SSH: Убедитесь, что конфигурация OpenSSH на сервере не нарушена. Ваш файл конфигурации
ssh_config
не содержит явных ошибок, но стоит проверить и другие параметры, такие какCiphers
,MACs
, иKexAlgorithms
. Если вы внесли изменения в конфигурацию, убедитесь, что серверный процессsshd
перезапущен. -
Ошибки в службе
sshd
: Выполнение команды/sbin/sshd
вместо стандартногоsystemctl restart sshd
может указывать на проблемы с обработкой прав доступа или параметров запуска сервиса. Рассмотрите возможность проверки системных логов (например,/var/log/secure
илиjournalctl -u sshd
) для выявления ошибок или предупреждений, которые могут указывать на более глубокие проблемы. -
Критические возможности и права в контейнерах: Если вы работаете в контейнере, параметры безопасности, такие как
SYS_CHROOT
,AUDIT_CONTROL
, иAUDIT_WRITE
, могут быть необходимы. Убедитесь, что не только сам сервис, но и окружение, в котором он работает, правильно настроены.
Общие рекомендации по устранению неполадок
-
Проверка подключений: Используйте команду
ping
для проверки доступности сервера. Кроме того, можно использоватьtraceroute
для диагностики маршрута до сервера. -
Перезапуск сетевых настроек: Иногда смена MTU и перезапуск сетевых интерфейсов может помочь решить проблемы. Используйте команды:
ip link set dev eth0 mtu 576 systemctl restart network
-
Проверка состояния службы sshd:
systemctl status sshd journalctl -xe | grep sshd
-
Тестирование с других клиентов: Попробуйте подключиться к серверу с разных клиентов или устройств (напр., используя PuTTY на Windows или другой Linux-клиент).
-
Обновление и переустановка OpenSSH: Если проблема не решается, рассмотрите возможность обновления или переустановки OpenSSH. Обновления могут содержать исправления для известных ошибок.
Заключение
Проблема с "Connection reset/closed by server after SSH2_MSG_KEXINIT" может быть сложной для диагностики, так как она может касаться как сетевых настроек, так и конфигураций программного обеспечения. Следуйте предоставленным рекомендациям, чтобы шаг за шагом определить корень проблемы и устранить её. При необходимости, не стесняйтесь обращаться к сообществу или профессионалам для получения дальнейшей помощи.