Вопрос или проблема
Я пытаюсь настроить сервер Debian 12, и не могу сделать так, чтобы он принимал SSH-соединения с моего компьютера на Ubuntu 22.04 (или со старого компьютера на Ubuntu). Он не запрашивает пароль; команда SSH просто завершает работу сразу же. SSH на localhost и [IP Debian 12] работают – запрашивают пароль, принимают его и выполняют вход. Это должно быть почти стандартная установка Debian 12. Я даже попытался скопировать стандартный файл sshd_config с компьютера на Ubuntu 22.04 (который принимает соединения с машины Debian) на машину Debian, но безуспешно.
Вот что говорит машина на Ubuntu 22.04, когда я пытаюсь установить соединение:
[localuser]@[localmachine]:~$ ssh -vvv [remoteuser]@192.168.2.9
OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 19: включение /etc/ssh/ssh_config.d/*.conf не соответствует ни одному файлу
debug1: /etc/ssh/ssh_config строка 21: Применение параметров для *
debug2: resolve_canonicalize: hostname 192.168.2.9 это адрес
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/[localuser]/.ssh/known_hosts'
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/[localuser]/.ssh/known_hosts2'
debug3: ssh_connect_direct: вход
debug1: Подключение к 192.168.2.9 [192.168.2.9] порт 22.
debug3: set_sock_tos: установить сокет 3 IP_TOS 0x10
debug1: Соединение установлено.
debug1: файл личной сущности /home/[localuser]/.ssh/id_rsa тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_rsa-cert тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_ecdsa тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_ecdsa-cert тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_ecdsa_sk тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_ed25519 тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_ed25519-cert тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_ed25519_sk тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_ed25519_sk-cert тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_xmss тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_xmss-cert тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_dsa тип -1
debug1: файл личной сущности /home/[localuser]/.ssh/id_dsa-cert тип -1
debug1: Строка локальной версии SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
kex_exchange_identification: read: Соединение сброшено одноранговым
Соединение сброшено 192.168.2.9 порт 22
Вот что сообщает машина Debian:
root@[Debian]:/etc/ssh# service sshd status
● ssh.service - сервер OpenBSD Secure Shell
Loaded: загружен (/lib/systemd/system/ssh.service; включен; предустановлен: включен)
Active: активен (работает) с Чт 2024-12-05 20:13:30 EST; 8 мин назад
Docs: man:sshd(8)
man:sshd_config(5)
Process: 3052 ExecStartPre=/usr/sbin/sshd -t (код=выход, статус=0/УСПЕХ)
Main PID: 3054 (sshd)
Tasks: 1 (ограничение: 4269)
Memory: 1.4M
CPU: 211ms
CGroup: /system.slice/ssh.service
└─3054 "sshd: /usr/sbin/sshd -D [listener] 0 из 10-100 запусков"
Dec 05 20:13:30 [Debian] systemd[1]: Запуск ssh.service - сервер OpenBSD Secure Shell...
Dec 05 20:13:30 [Debian] sshd[3054]: Сервер слушает на 0.0.0.0 порт 22.
Dec 05 20:13:30 [Debian] sshd[3054]: Сервер слушает на :: порт 22.
Dec 05 20:13:30 [Debian] systemd[1]: Запущен ssh.service - сервер OpenBSD Secure Shell.
root@[Debian]:/etc/ssh# journalctl --since "2 минуты назад"
-- Нет записей --
root@[Debian]:/etc/ssh#
Конфигурационный файл в настоящее время выглядит так:
# Это системный конфигурационный файл sshd. Смотрите
# sshd_config(5) для получения более подробной информации.
# Этот sshd был скомпилирован с PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
# Стратегия, используемая для параметров в стандартном sshd_config, поставляемом с
# OpenSSH, заключается в том, чтобы указывать параметры с их значением по умолчанию, где
# это возможно, но оставлять их закомментированными. Не закомментированные параметры переопределяют
# значение по умолчанию.
Include /etc/ssh/sshd_config.d/*.conf
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Шифры и ключи
#RekeyLimit по умолчанию нет
# Логирование
#SyslogFacility AUTH
#LogLevel INFO
# Аутентификация:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# Ожидается, что .ssh/authorized_keys2 будет игнорироваться по умолчанию в будущем.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# Для того чтобы это работало, вам также понадобятся ключи хоста в /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Измените на yes, если вы не доверяете ~/.ssh/known_hosts для
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Не читайте файлы ~/.rhosts и ~/.shosts пользователя
#IgnoreRhosts yes
# Чтобы отключить туннелированные пароли в открытом текстовом формате, измените на no здесь!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Измените на yes, чтобы включить пароли с вопросами и ответами (осторожно, проблемы с
# некоторыми модулями PAM и потоками)
KbdInteractiveAuthentication no
# Опции Kerberos
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# Опции GSSAPI
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Установите это в 'yes', чтобы включить аутентификацию PAM, обработку учетной записи,
# и обработку сессий. Если это включено, аутентификация PAM будет
# разрешена через KbdInteractiveAuthentication и
# PasswordAuthentication. В зависимости от вашей конфигурации PAM,
# аутентификация PAM через KbdInteractiveAuthentication может обойти
# установку "PermitRootLogin without-password".
# Если вы просто хотите, чтобы проверки учетной записи и сессий PAM выполнялись без
# аутентификации PAM, то включите это, но установите PasswordAuthentication
# и KbdInteractiveAuthentication в 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# нет стандартного пути баннера
#Banner none
# Позволить клиенту передавать локальные переменные окружения
AcceptEnv LANG LC_*
# переопределение параметров по умолчанию без подсистем
Subsystem sftp /usr/lib/openssh/sftp-server
# Пример переопределения настроек для каждого пользователя
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Есть идеи, что может быть не так? Обратите внимание, что я не устанавливал и не настраивал никаких программ для брандмауэра, но возможно, что-то стандартное, о чем я не осведомлён.
Ответ или решение
Проблема с подключением по SSH к серверу Debian 12 может быть связана с несколькими факторами, и поэтому необходимо провести детальный анализ. Рассмотрим шаги, которые могут помочь в диагностике и решении проблемы.
1. Проверка состояния службы SSH
Сначала убедитесь, что служба SSH правильно запущена на сервере Debian. Вы уже указали, что служба активна и работает. Следовательно, это не является основной причиной проблемы.
service sshd statusЕсли служба активная, перейдите к следующему шагу.
2. Анализ конфигурации SSH
Ваш файл конфигурации sshd_config на первый взгляд выглядит стандартно, однако важно проверить некоторые параметры:
-
Порт и адреса прослушивания: Убедитесь, что строки
Port 22,ListenAddress 0.0.0.0иListenAddress ::не закомментированы. Если настройки закомментированы или неверны, сервер может не принимать подключения.Port 22 ListenAddress 0.0.0.0 -
Аутентификация: Убедитесь, что аутентификация паролем разрешена:
PasswordAuthentication yes -
PAM: Убедитесь, что
UsePAMустановлено вyes, что позволит использовать модули PAM для аутентификации.
После внесения любых изменений, не забудьте перезапустить сервис SSH:
sudo systemctl restart ssh3. Проверка сетевых настроек
Убедитесь, что порт 22 открыт и доступен для входящих подключений. Попробуйте выполнить команду на машине с Ubuntu, чтобы проверить, доступен ли порт:
telnet 192.168.2.9 22Если соединение невозможно, значит, есть проблема на уровне сети, например, настройки маршрутизатора или блокировка порта.
4. Информация о подключении
При выполнении команды ssh -vvv [remoteuser]@192.168.2.9 вы получили сообщение об ошибке kex_exchange_identification: read: Connection reset by peer. Это часто говорит о том, что сервер SSH по какой-то причине закрыл соединение. Это может быть связано с:
- Перегрузкой ресурсов: Если на сервере происходит высокая загрузка, это может повлиять на установление соединений.
- Ошибками в конфигурации: Как уже упоминалось ранее, проверьте конфигурацию SSH и убедитесь, что нет ошибок.
5. Проверка настройки фаервола
Хотя вы упомянули, что не устанавливали специальное программное обеспечение для брандмауэра, стоит проверить наличие встроенных средств контроля доступа. Например, убедитесь, что ufw (Uncomplicated Firewall) либо отключен, либо настроен так, чтобы разрешать SSH подключения.
Проверьте состояние ufw:
sudo ufw statusЕсли он активирован и порт 22 закрыт, добавьте правило для разрешения SSH:
sudo ufw allow ssh6. Операционная система и журналы
Проверьте журналы событий для получения более детальной информации о возможных ошибках. Используйте команду:
sudo journalctl -u sshЭто может помочь выявить проблему, если она связана с ошибками в работе службы SSH.
Заключение
Следуя предложенным рекомендациям, вы сможете выявить и устранить проблему с подключением по SSH к вашему серверу Debian 12. Подход к решению вопросов сетевой аутентификации всегда требует тщательной проверки конфигураций, состояния служб и сетевых настроек. Если проблема сохраняется, стоит рассмотреть возможность обращения к профессионалам или сообществу, чтобы получить дополнительную поддержку.