Вопрос или проблема
Я создал новый сервер на Ubuntu 24.
Мой ноутбук Mac 2023 года может подключаться к серверу по ssh, но мой Mac Mini M4 2024 года не может.
Когда я запускаю ssh в режиме повышенной детализации на неработающем Mac Mini, выводится следующий результат:
% ssh -vvvv [email protected]
OpenSSH_9.8p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/atlantageek/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 22: Including file /etc/ssh/ssh_config.d/100-macos.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/100-macos.conf
debug1: /etc/ssh/ssh_config.d/100-macos.conf line 1: Applying options for *
debug3: /etc/ssh/ssh_config.d/100-macos.conf line 3: Including file /etc/ssh/crypto.conf depth 1
debug1: Reading configuration data /etc/ssh/crypto.conf
debug3: kex names ok: [ecdh-sha2-nistp256]
debug2: resolve_canonicalize: hostname 10.0.0.231 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/atlantageek/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/atlantageek/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 10.0.0.231 [10.0.0.231] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /Users/atlantageek/.ssh/id_rsa type -1
debug1: identity file /Users/atlantageek/.ssh/id_rsa-cert type -1
debug1: identity file /Users/atlantageek/.ssh/id_ecdsa type -1
debug1: identity file /Users/atlantageek/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/atlantageek/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/atlantageek/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/atlantageek/.ssh/id_ed25519 type -1
debug1: identity file /Users/atlantageek/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/atlantageek/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/atlantageek/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/atlantageek/.ssh/id_xmss type -1
debug1: identity file /Users/atlantageek/.ssh/id_xmss-cert type -1
debug1: identity file /Users/atlantageek/.ssh/id_dsa type -1
debug1: identity file /Users/atlantageek/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.8
kex_exchange_identification: read: Connection reset by peer
Connection reset by 10.0.0.231 port 22
Режим подробного вывода ssh на ноутбуке возвращает:
OpenSSH_9.0p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/tommiejones/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug2: resolve_canonicalize: hostname 10.0.0.231 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/tommiejones/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/tommiejones/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: ssh_connect_direct: entering
debug1: Connecting to 10.0.0.231 [10.0.0.231] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /Users/tommiejones/.ssh/id_rsa type 0
debug1: identity file /Users/tommiejones/.ssh/id_rsa-cert type -1
debug1: identity file /Users/tommiejones/.ssh/id_ecdsa type -1
debug1: identity file /Users/tommiejones/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/tommiejones/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/tommiejones/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/tommiejones/.ssh/id_ed25519 type 3
debug1: identity file /Users/tommiejones/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/tommiejones/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/tommiejones/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/tommiejones/.ssh/id_xmss type -1
debug1: identity file /Users/tommiejones/.ssh/id_xmss-cert type -1
debug1: identity file /Users/tommiejones/.ssh/id_dsa type -1
debug1: identity file /Users/tommiejones/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6p1 Ubuntu-3ubuntu13.8
debug1: compat_banner: match: OpenSSH_9.6p1 Ubuntu-3ubuntu13.8 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.0.231:22 as 'tj'
debug3: record_hostkey: found key type ED25519 in file /Users/tommiejones/.ssh/known_hosts:84
debug3: record_hostkey: found key type RSA in file /Users/tommiejones/.ssh/known_hosts:85
debug3: record_hostkey: found key type ECDSA in file /Users/tommiejones/.ssh/known_hosts:86
debug3: load_hostkeys_file: loaded 3 keys from 10.0.0.231
debug1: load_hostkeys: fopen /Users/tommiejones/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: have matching best-preference key type [email protected], using HostkeyAlgorithms verbatim
debug3: send packet: type 20
Не уверен, что произошло. Я разрешил обновления, и после перезагрузки ssh заработал.
.
Ответ или решение
Для начала, давайте разберем теорию работы SSH и причины возможных неполадок при подключении. SSH (Secure Shell) — это протокол сетевой безопасности, который используется для безопасного соединения между устройствами, позволяющий пользователям управлять серверами и компьютерными системами удаленно. Протокол SSH обеспечивает конфиденциальность и целостность данных благодаря использованию двух ключей: публичного и приватного.
Теперь перейдем к более конкретному анализу проблемы, описанной в вашем вопросе. Ваша ситуация включает несколько основных аспектов:
-
Операционная система: Вы упоминаете, что используете новые версии ОС: Ubuntu 24 на сервере и MacOS на вашем Mac Mini. Различия между этими системами могут быть причиной некорректной работы.
-
Версии SSH: Исходя из логов, можно увидеть, что разные устройства используют разные версии OpenSSH. На Mac Mini используется OpenSSH_9.8p1, а на ноутбуке — OpenSSH_9.0p1. Различия между версиями могут содержать обновления, которые изменяют метод работы или требования к конфигурации, что может вызвать несовместимость.
-
Логирование и ошибка: Из подробного вывода команды ssh на Mac Mini можно увидеть, что проблемой является сбой связи, обозначенный как "kex_exchange_identification: read: Connection reset by peer". Это указывает на разрыв соединения с сервером после установки начального соединения, что может происходить по ряду причин, таких как ограничение по IP, изменения настроек конфигурации сервера, сетевые проблемы или ошибки в алиасах SSH.
Примеры диагностики подобных проблем:
-
Проблемы с конфигурацией: При несовпадении настроек протокола в конфигурационных файлах SSH клиента или сервера могут возникнуть проблемы с подключением. Это может быть связано с недавно внедренными политиками безопасности в последних версиях OpenSSH, которые требуют соответствия определённым стандартам или же отключения некоторых типов ключей.
-
Обновление системы: Во многих случаях, особенно с новыми версиями систем и ПО, различие в обновлениях может повлиять на работоспособность сервисов. Как вы отметили в конце описания проблемы, после установки всех доступных обновлений и перезапуска, соединение начало работать корректно.
Применение и решение проблемы:
-
Проверка конфигурации: Убедитесь, что файлы конфигурации
/etc/ssh/ssh_configи~/.ssh/configсодержат корректные и совместимые параметры. Обратите внимание на секции с алгоритмами шифрования, аутентификации и типами ключей, которые должен поддерживать как клиент, так и сервер. -
Сопоставление версий: Одинаковые версии ПО на клиенте и сервере обеспечивают большую стабильность работы. Убедитесь, что все обновления OpenSSH и других зависимых пакетов установлены как на сервере, так и на клиентских устройствах.
-
Диагностика сетевых ограничений: Используйте команды
pingиtracerouteдля проверки сетевого соединения между устройствами. Возможно, существуют межсетевые экраны, которые блокируют входящие или исходящие запросы на вашем сервере Ubuntu или в локальной сети. Убедитесь, что соответствующие порты открыты (особенно порт 22 для SSH). -
Проверка ключей аутентификации: Убедитесь в том, что все SSH-ключи правильны и существуют в директориях ожидаемых на сервере (например, в
~/.ssh/authorized_keys). Инвалидные или устаревшие ключи могут быть причиной отказа подключения.
Ваш случай демонстрирует, что проблема заключалась в несовпадении настроек и исправлена обновлениями, однако знание вышеперечисленных подходов поможет в будущих ситуациях, когда могут возникнуть похожие проблемы. Успешное разрешение проблемы демонстрирует важность регулярного обновления систем и хороший контроль над конфигурацией сетевых компонентов.