Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Системное администрирование и сети

SSH: Сброс соединения по порту 22 (та же подсеть)

На чтение 8 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Возможные причины
  4. Решения
  5. Итог

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

Я настраиваю публичный сервер A у себя дома, просто обычный телекоммуникационный маршрутизатор. Дело в том, что я могу подключаться по SSH к серверу A из внешней сети, но при попытке соединения из локальной сети, где у меня такой же подсеть, появляется ошибка “сброс соединения”.

Вот журнал внутреннего SSH-соединения:

ssh -vvv [email protected] -p 22                                                                                                                255 ↵ enderphan@Mac
OpenSSH_9.8p1, LibreSSL 3.3.6
debug1: Чтение конфигурационных данных /Users/enderphan/.ssh/config
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 21: include /etc/ssh/ssh_config.d/* не совпадает ни с одним файлом
debug1: /etc/ssh/ssh_config строка 55: Применение параметров для *
debug2: resolve_canonicalize: имя хоста 192.168.1.24 является адресом
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/enderphan/.ssh/known_hosts'
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/enderphan/.ssh/known_hosts2'
debug1: Поставщик аутентификации $SSH_SK_PROVIDER не был найден; отключение
debug3: channel_clear_timeouts: очищение
debug3: ssh_connect_direct: вход
debug1: Подключение к 192.168.1.24 [192.168.1.24] порт 22.
debug3: set_sock_tos: установка сокета 3 IP_TOS 0x48
debug1: Соединение установлено.
debug1: файл идентификации /Users/enderphan/.ssh/id_rsa тип 0
debug1: файл идентификации /Users/enderphan/.ssh/id_rsa-cert тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_ecdsa тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_ecdsa-cert тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_ecdsa_sk тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_ed25519 тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_ed25519-cert тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_ed25519_sk тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_ed25519_sk-cert тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_xmss тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_xmss-cert тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_dsa тип -1
debug1: файл идентификации /Users/enderphan/.ssh/id_dsa-cert тип -1
debug1: Локальная версия SSH-2.0-OpenSSH_9.8
debug1: Удаленная версия протокола 2.0, удаленная версия программного обеспечения OpenSSH_9.6p1 Ubuntu-3ubuntu13.5
debug1: compat_banner: совпадение: OpenSSH_9.6p1 Ubuntu-3ubuntu13.5 pat OpenSSH* compat 0x04000000
debug2: fd 3 установка O_NONBLOCK
debug1: Аутентификация к 192.168.1.24:22 как 'ender'
debug3: record_hostkey: найден ключ типа ED25519 в файле /Users/enderphan/.ssh/known_hosts:35
debug3: load_hostkeys_file: загружен 1 ключ из 192.168.1.24
debug1: load_hostkeys: fopen /Users/enderphan/.ssh/known_hosts2: Нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: Нет такого файла или каталога
debug3: order_hostkeyalgs: есть совпадающий ключ предпочтения [email protected], используем HostkeyAlgorithms в точности
debug3: отправка пакета: тип 20
debug1: SSH2_MSG_KEXINIT отправлено
debug3: получение пакета: тип 20
debug1: SSH2_MSG_KEXINIT получено
debug2: локальный клиент KEXINIT предложение
debug2: алгоритмы KEX: [email protected],curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,[email protected]
debug2: алгоритмы ключа хоста: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256
debug2: шифры ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: шифры stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: сжатие ctos: none,[email protected],zlib
debug2: сжатие stoc: none,[email protected],zlib
debug2: языки ctos:
debug2: языки stoc:
debug2: first_kex_follows 0
debug2: зарезервировано 0
debug2: peer server KEXINIT предложение
debug2: алгоритмы KEX: [email protected],curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-s,[email protected]
debug2: алгоритмы ключа хоста: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: шифры ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: шифры stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: сжатие ctos: none,[email protected]
debug2: сжатие stoc: none,[email protected]
debug2: языки ctos:
debug2: языки stoc:
debug2: first_kex_follows 0
debug2: зарезервировано 0
debug3: отправка пакета: тип 5
debug3: получение пакета: тип 7
debug1: SSH2_MSG_EXT_INFO получено
debug3: kex_input_ext_info: расширение server-sig-algs
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256>
debug3: kex_input_ext_info: расширение [email protected]
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug3: kex_input_ext_info: расширение [email protected]
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug3: получение пакета: тип 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug3: отправка пакета: тип 50
Соединение сброшено с 192.168.1.24 порт 22

Тем временем сервер A выводит журналы, которые приходят от шлюза… какого черта?

2024-09-22T17:47:04.874145+07:00 RTX sshd[45506]: Соединение сброшено с 192.168.1.1 порт 62224 [preauth]

Похоже, что IP-адрес моего Macos проходит через шлюз 192.168.1.1 вместо того, чтобы направляться напрямую к серверу A? И я не знаю, почему соединение было сброшено.

Вот моя настройка проброса портов:

введите текст описания здесь

Есть ли у вас идеи, как сделать так, чтобы мое внутреннее SSH-соединение заработало? Я пытался удалить правило проброса портов, и оно работает из внутренней сети, но извне не удается.

Ответ или решение

Проблема с подключением по SSH, обостренная сообщением "Connection reset by port 22", указывает на то, что ваш Mac пытается подключиться к серверу A (192.168.1.24) через маршрутизатор, который выступает в роли шлюза (192.168.1.1). Введенные данные показывают, что SSH-соединение сбрасывается на уровне соединения, и это может быть вызвано несколькими причинами. Давайте разберем возможные причины и пути решения.

Возможные причины

  1. Маршрутизация через шлюз: Когда вы подключаетесь к серверу A (локально), пакеты могут проходить через маршрутизатор, что может нарушать соединение, если он неправильно настроен.

  2. Настройки SSH на сервере A: Возможно, в конфигурации SSH-сервера есть ограничения по IP-адресам, и внутренние подключения блокируются.

  3. Фаервол: На маршрутизаторе или на сервере могут быть включены правила фаервола, которые блокируют SSH-подключения с определенных IP-адресов.

  4. Конфликт портов: Порт, на который происходит попытка подключения, может быть занят другим процессом или неправильно перенаправляться.

Решения

  1. Проверка конфигурации SSH на сервере A:

    • Убедитесь, что файл конфигурации SSH /etc/ssh/sshd_config на сервере A допускает внутренние подключения. Проверьте строки AllowUsers, если они есть, и уберите из них IP-адреса, блокирующие доступ.

  2. Изменение маршрута:

    • Попробуйте подключиться к серверу A не по внутреннему IP-адресу (например, 192.168.1.24), а используя специальный -b параметр в SSH. Пример команды: ssh -b 192.168.1.24 [email protected].

  3. Настройка фаервола и маршрутизатора:

    • Проверьте настройки фаервола как на сервере, так и на маршрутизаторе. Убедитесь, что порт 22 открыт для внутренних подключений. Если вы используете UFW на сервере, вы можете ввести команды: 
      sudo ufw allow from 192.168.1.0/24 to any port 22

  4. Перенастройка маршрутизации:

    • Если ваш маршрутизатор управляет политикой маршрутизации, попробуйте временно отключить маршрутизатор и подключиться напрямую к серверу A, чтобы проверить, происходит ли сбой.

  5. Проверка сетевого трафика:

    • Попробуйте использовать утилиты такие как tcpdump или wireshark на шлюзе, чтобы проследить, проходят ли пакеты от вашего Mac к серверу A и в чем заключается точная проблема с соединением.

  6. Использование локального DNS:

    • Иногда проблема может быть связана с разрешением DNS. Попробуйте использовать утилиту ping на 192.168.1.24, чтобы проверить, доступен ли сервер по этому адресу.

Итог

Если после выполнения всех шагов проблема не решится, может потребоваться более глубокая диагностика сети. Также стоит проверить логи SSH на сервере A за дополнительные ошибки, которые могут помочь с диагностикой. Убедитесь, что используете актуальную версию OpenSSH и выполните все обновления на системе.

Если все шаги будут пройдены, но проблема сохранится, вероятно, потребуется задействовать специалистов по сетевым технологиям для дополнительной помощи в troubleshooting.

internal linux-networking ssh
Оцените материал
Добавить комментарий

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

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности