SSH разрешает вход, но не запускает командную строку.

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

Используется AlmaLinux release 9.5 (Teal Serval).

Когда пользователь пытается войти в систему через SSH, система принимает вход и затем зависает перед отключением. Даже root пользователь (которому мы строго разрешили)

Если я использую Bitvise SSH Client, устанавливаю соединение, открываю SFTP-сеанс, закрываю его, а затем пытаюсь подключиться через терминал, вход выполняется без проблем.


# Это файл системной конфигурации сервера sshd. См.
# sshd_config(5) для получения дополнительной информации.

# Этот sshd был скомпилирован с PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

# Стратегия, используемая для опций в sshd_config по умолчанию, поставляемого с
# OpenSSH, состоит в том, чтобы указывать опции со значениями по умолчанию там, где
# возможно, но оставлять их закомментированными. Раскомментированные опции переопределяют
# значение по умолчанию.

# Чтобы изменить системную конфигурацию sshd, создайте файл *.conf в
# /etc/ssh/sshd_config.d/, который будет автоматически включен ниже
Include /etc/ssh/sshd_config.d/*.conf

# Если вы хотите изменить порт в системе SELinux, необходимо информировать
# SELinux об этом изменении.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#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 default none

# Логирование
#SyslogFacility AUTH
#LogLevel INFO

# Аутентификация:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# По умолчанию проверяются обе .ssh/authorized_keys и .ssh/authorized_keys2,
# но это переопределено, чтобы установки проверяли только .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

#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

# Изменить на no для отключения паролей s/key
#KbdInteractiveAuthentication yes

# Настройки Kerberos
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# Настройки GSSAPI
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Установите на 'yes', чтобы включить аутентификацию PAM, обработку учетной записи
# и обработку сеансов. Если это включено, аутентификация PAM будет
# разрешена через KbdInteractiveAuthentication и
# PasswordAuthentication. В зависимости от вашей конфигурации PAM,
# аутентификация PAM через KbdInteractiveAuthentication может обойти
# настройку "PermitRootLogin without-password".
# Если вы хотите, чтобы проверки учетной записи и сеанса PAM работали без
# аутентификации PAM, включите это, но установите значения PasswordAuthentication
# и KbdInteractiveAuthentication на 'no'.
# ВНИМАНИЕ: 'UsePAM no' не поддерживается в RHEL и может вызвать несколько
# проблем.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# нет пути баннера по умолчанию
#Banner none

# переопределить отсутствие подсистем по умолчанию
Subsystem   sftp    /usr/libexec/openssh/sftp-server

# Пример переопределения настроек для конкретного пользователя
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

Эта система обеспечивает управление радиоретранслятором группы экстренной связи.

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

Чтобы решить задачу с SSH-соединением, которое позволяет войти в систему, но не запускает командную строку, необходимо учесть несколько аспектов. Мы рассматриваем систему AlmaLinux 9.5, и в конфигурации SSH могут быть скрыты некоторые нюансы. Проанализируем текущее положение и предложим возможные пути решения.

Теория (Theory):

SSH (Secure Shell) — это протокол сетевой безопасности, позволяющий безопасный доступ к удалённым системам. При подключении через SSH клиент отправляет запрос серверу, который аутентифицирует пользователя и открывает сеанс командной строки.

Когда SSH принимает вход, но не запускает командную строку, проблема может быть связана с несколькими факторами. Это могут быть настройки PAM (Pluggable Authentication Modules), ошибки в начальных скриптах пользователя (например, .bashrc или .profile), ограничения прав доступа или более специфические параметры в конфигурации SSH (sshd_config).

Пример (Example):

Ваша ситуация специфична: вход через SSH проходит успешно, но затем система зависает. Однако, если сначала открыть сеанс SFTP, а затем попробовать терминальный вход — всё работает. Это может указывать на проблему, связанную с инициализацией оболочки или сессии пользователя.

Конфигурационный файл SSH (sshd_config), который вы предоставили, не показывает явных проблем в разрешённых ограничениях (например, PermitRootLogin yes). Однако есть несколько комментированных строк, которые могут влиять на поведение системы — например, UsePAM и другие параметры, связанные с аутентификацией и инициализацией сессии.

Применение (Application):

Вот несколько шагов для диагностики и решения проблемы:

Проверка PAM: Если система использует PAM для аутентификации и управления сессиями, его неверная конфигурация может мешать правильной инициализации сеанса. Проверьте содержимое файлов /etc/pam.d/sshd и /etc/pam.d/sshd_session, чтобы убедиться, что сеанс инициализируется корректно. Возможно, потребуется включить параметры, такие как session required pam_namespace.so, если они отсутствуют.
Оболочка пользователя: Убедитесь, что оболочка пользователя (например, bash) и связанные начальные скрипты загружаются без ошибок. Проверьте .bashrc, .bash_profile, .profile и другие файлы, чтобы убедиться в отсутствии ошибок или команд, блокирующих выполнение сеанса.
Конфигурация SSH: Попробуйте временно изменить некоторые параметры в sshd_config. Включите UsePAM yes, если он отключен, и посмотрите, есть ли изменения. Запустите sshd в режиме отладки (например, sshd -d) для получения более детальной информации о проблемах.
Журналы и логи: Изучите системные журналы, такие как /var/log/secure и /var/log/messages, которые могут содержать записи об ошибках, происходящих во время инициализации SSH-сессии.
SELinux и AppArmor: Если система использует SELinux или AppArmor, убедитесь, что они не блокируют выполнение некоторых процессов или скриптов. Пробуйте временно отключить их для проверки.

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

Подытоживая, проблема с "SSH принимает вход, но не запускает командную строку" может быть сложной, но с систематическим подходом её вполне можно решить. Внимательная проверка конфигурационных файлов, корректировка параметров PAM, изучение начальных скриптов оболочки и анализ системных логов — всё это составляющие успешного решения проблемы.