#Что происходит и когда это важно
В подробном выводе клиент получает подтверждение ключа, затем соединение закрывается, показывает только текст команды или сообщает о невозможности запустить shell.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Учётной записи назначен nologinАккаунт предусмотрен для сервиса или SFTP без shell. | getent passwd показывает /usr/sbin/nologin или /bin/false. | Не менять shell служебного пользователя без политики. |
| Настроен ForceCommand или restricted keysshd запускает заранее заданную команду. | В конфигурации/authorized_keys есть command= или ForceCommand. | Сверить назначение ограниченного доступа. |
| Проблема с домашним каталогом/PAMСеанс закрывается после авторизации из-за недоступных файлов или системной политики. | В журнале sshd/PAM ошибка после accepted publickey. | Проверить доступ, ресурсы и лимиты. |
#Пошаговая диагностика и исправление
- Подтвердите, что ключ действительно принятНа клиенте выполните
ssh -v пользователь@сервер. ИщитеAuthenticated to .../Server accepts key, а затем точное сообщение о закрытии; не публикуйте полный вывод с сетевыми адресами и именами. - Откройте серверную консольПопросите администратора войти через локальную консоль или резервный доступ. Не меняйте sshd_config в единственном рабочем SSH-сеансе — можно потерять удалённый доступ. Если консоли нет, попросите владельца сохранить текущий рабочий сеанс и подготовить безопасный способ возврата.
- Проверьте назначенную оболочкуНа сервере выполните
getent passwd ИМЯ_ПОЛЬЗОВАТЕЛЯ. Последнее поле — shell. Если это nologin/false, учётная запись, вероятно, не предназначена для терминала; не «исправляйте» сервисного пользователя назначением /bin/bash без проверки назначения. - Проверьте ограничивающие правилаАдминистратор может выполнить
sudo sshd -T -C user=ИМЯ,host=ИМЯ_ХОСТА,addr=IPс действительными значениями и посмотреть ForceCommand, PermitTTY, ChrootDirectory; отдельно проверить опцииcommand=иrestrictв соответствующем публичном ключе без вывода секрета. - Посмотрите журнал после авторизацииВыполните
sudo journalctl -u ssh -b -n 100 --no-pagerлибо-u sshdсогласно имени службы. Ищите session opened/closed, PAM, невозможность создать процесс, отсутствие каталога или command forced. Причина может быть в оболочке даже при исправном ключе. - Проверьте корректность shell и домашнего каталогаЕсли интерактивный доступ действительно должен быть разрешён, сверяйтесь с требованиями организации: существует ли исполняемый файл shell, домашний каталог и права. Изменять пользовательскую оболочку должен только администратор с сохранением исходного значения и пониманием влияния на сервисы.
- Проверьте новый сеансПосле согласованного изменения повторите SSH, выполните безопасную команду
pwdи выйдитеexit. Если это SFTP-only аккаунт, проверяйте вход черезsftp, а не требуйте оболочку, которая намеренно отключена.
#Команды из инструкции с пояснениями
Linux · Терминал (Bash)Команда
Сервер: последняя колонка показывает shell.
getent passwd ИМЯ_ПОЛЬЗОВАТЕЛЯLinux · Терминал (Bash)Команда
Клиент: последовательность аутентификации и открытия сессии.
ssh -v пользователь@серверLinux · Терминал (Bash)КомандаНужен sudo
Сервер Debian/Ubuntu: последние записи SSH службы; администратор.
sudo journalctl -u ssh -b -n 100 --no-pager#Как проверить результат
Обычный пользователь получает предусмотренную интерактивную оболочку, а специальный SFTP-only пользователь по-прежнему ограничен согласно политике.
#Если проблема не устранена
Если сервер закрывает сессию после успешной авторизации, соберите журнал в момент ошибки и фактическую конфигурацию Match/ForceCommand. Не отключайте PAM или SSH ограничения наугад.