Соединение сброшено/закрыто сервером после отправки SSH2_MSG_KEXINIT в SSH

Вопрос или проблема

Я перезапустил свой сервер 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). Это может указывать на несколько проблем:

  1. Проблемы с MTU: Одной из частых причин подобного поведения является несоответствие настроек MTU (Maximum Transmission Unit). Если MTU настроен неправильно, это может привести к сбоям соединения. В вашем случае использование команды ifconfig eth0 mtu 576 решило проблему. Рекомендуется также применять аналогичное значение MTU на клиентской стороне.

  2. Проблемы с конфигурацией SSH: Убедитесь, что конфигурация OpenSSH на сервере не нарушена. Ваш файл конфигурации ssh_config не содержит явных ошибок, но стоит проверить и другие параметры, такие как Ciphers, MACs, и KexAlgorithms. Если вы внесли изменения в конфигурацию, убедитесь, что серверный процесс sshd перезапущен.

  3. Ошибки в службе sshd: Выполнение команды /sbin/sshd вместо стандартного systemctl restart sshd может указывать на проблемы с обработкой прав доступа или параметров запуска сервиса. Рассмотрите возможность проверки системных логов (например, /var/log/secure или journalctl -u sshd) для выявления ошибок или предупреждений, которые могут указывать на более глубокие проблемы.

  4. Критические возможности и права в контейнерах: Если вы работаете в контейнере, параметры безопасности, такие как SYS_CHROOT, AUDIT_CONTROL, и AUDIT_WRITE, могут быть необходимы. Убедитесь, что не только сам сервис, но и окружение, в котором он работает, правильно настроены.

Общие рекомендации по устранению неполадок

  1. Проверка подключений: Используйте команду ping для проверки доступности сервера. Кроме того, можно использовать traceroute для диагностики маршрута до сервера.

  2. Перезапуск сетевых настроек: Иногда смена MTU и перезапуск сетевых интерфейсов может помочь решить проблемы. Используйте команды:

    ip link set dev eth0 mtu 576
    systemctl restart network
  3. Проверка состояния службы sshd:

    systemctl status sshd
    journalctl -xe | grep sshd
  4. Тестирование с других клиентов: Попробуйте подключиться к серверу с разных клиентов или устройств (напр., используя PuTTY на Windows или другой Linux-клиент).

  5. Обновление и переустановка OpenSSH: Если проблема не решается, рассмотрите возможность обновления или переустановки OpenSSH. Обновления могут содержать исправления для известных ошибок.

Заключение

Проблема с "Connection reset/closed by server after SSH2_MSG_KEXINIT" может быть сложной для диагностики, так как она может касаться как сетевых настроек, так и конфигураций программного обеспечения. Следуйте предоставленным рекомендациям, чтобы шаг за шагом определить корень проблемы и устранить её. При необходимости, не стесняйтесь обращаться к сообществу или профессионалам для получения дальнейшей помощи.

Оцените материал
Добавить комментарий

Капча загружается...