Подробный гайд: Восстановление Fly, SSH, su в Astra Linux после установки Dallas Lock - Часть 2

Подробный гайд: Восстановление Fly, SSH, su в Astra Linux после установки Dallas Lock - Часть 2

5. Диагностика по симптомам

Ниже — практическая матрица: что не работает и куда смотреть.

5.1. Не работает ничего: ни SSH, ни su, ни локальный вход обычных пользователей

Вероятные причины:

1. Сломан общий PAM-стек:

• /etc/pam.d/common-auth;
• /etc/pam.d/common-account;
• /etc/pam.d/common-session;
• /usr/share/pam-configs/*.

2. Учётные записи заблокированы:

• faillock/pam_tally;
• пароль истёк;
• учётная запись просрочена.

---

---

3. Глобальные ограничения:

• /etc/nologin;
• /run/nologin;
• /etc/security/access.conf;
• /etc/security/time.conf;
• /etc/security/limits.conf;
• pam_exec со скриптом СЗИ.

4. СЗИ блокирует процесс аутентификации:

• PAM-модуль СЗИ падает;
• сервис СЗИ не запущен, а модуль требует его;
• лицензия недействительна;
• включён режим «запретить всё при сбое агента».

5. Системные проблемы:

• диск заполнен;
• файловая система read-only;
• сломаны /etc/passwd, /etc/shadow, /etc/group.

Что делать:

ls -l /etc/nologin /run/nologin 2>/dev/null
grep -vE '^\s*(#|$)' /etc/security/access.conf 2>/dev/null
grep -vE '^\s*(#|$)' /etc/security/time.conf 2>/dev/null
grep -R . /etc/security/limits.conf /etc/security/limits.d 2>/dev/null

Если видите строки СЗИ, временно отключите их только для диагностики и только если это разрешено политикой.

---

5.2. Локальный вход администратора работает, а обычные пользователи не входят

Смотрим:

• парольную политику конкретного пользователя;
• членство в группах;
• access.conf;
• AllowUsers/AllowGroups;
• политики СЗИ по пользователям/группам;
• мандатные уровни и метки;
• домашний каталог.

Проверка:

U=username
id "$U"
groups "$U"
chage -l "$U"
passwd -S "$U"
faillock --user "$U" 2>/dev/null || true
getent passwd "$U"
ls -ld /home/"$U"

---

5.3. SSH не работает, но локальный вход работает

Значит, проблема чаще всего в:

• службе ssh;
• конфигурации sshd;
• firewall;
• TCP Wrappers;
• fail2ban;
• pam_access;
• AllowUsers/AllowGroups;
• ключах и правах ~/.ssh;
• сетевом фильтре СЗИ.

Проверка:

systemctl status ssh sshd --no-pager || true
ss -ltnp | grep ':22'
/usr/sbin/sshd -t
/usr/sbin/sshd -T | grep -Ei '^(port|listenaddress|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication|usepam|permitrootlogin|allowusers|denyusers|allowgroups|denygroups|authenticationmethods|forcecommand|chrootdirectory|authorizedkeysfile|authorizedkeyscommand)'

Проверка с учётом конкретного пользователя и адреса:

/usr/sbin/sshd -T -C user=username,host=localhost,addr=127.0.0.1 | \
grep -Ei '^(allowusers|denyusers|allowgroups|denygroups|passwordauthentication|pubkeyauthentication|authenticationmethods|forcecommand|chrootdirectory)'

5.4. SSH подключается, но сразу закрывается

Типовые причины:

1. Пользовательская оболочка:

• неверный shell;
• shell отсутствует;
• /etc/passwd указывает на /usr/sbin/nologin или несуществующий путь.

2. Стартовые скрипты:

• /etc/profile;
• /etc/profile.d/*;
• ~/.profile;
• ~/.bashrc;
• ~/.xsession;
• /etc/X11/Xsession.d/*;
• ~/.ssh/rc;
• /etc/ssh/sshrc.

3. ForceCommand в sshd_config.

4. Ограничения СЗИ:

• скрипт проверки сеанса завершается ошибкой;
• блокируется оболочка;
• переменная LD_PRELOAD ломает процесс.

5. Ошибки PAM-сессии.

Проверка:

U=username
getent passwd "$U" | cut -d: -f7
ls -l "$(getent passwd "$U" | cut -d: -f7)" 2>/dev/null
bash -n /etc/profile 2>/dev/null
for f in /etc/profile.d/*.sh; do bash -n "$f" || echo "Syntax problem: $f"; done
bash -n /home/"$U"/.bashrc 2>/dev/null
bash -n /home/"$U"/.profile 2>/dev/null

Полезный тест:

ssh username@localhost /bin/true
ssh username@localhost 'echo ok'

Если /bin/true выполняется, а интерактивная сессия падает — вероятнее всего виноваты стартовые файлы, окружение или ForceCommand.

---

5.5. SSH не принимает пароль, но ключ работает

Смотрим:

/usr/sbin/sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|usepam|authenticationmethods)'

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

• PasswordAuthentication no;
• KbdInteractiveAuthentication no;
• AuthenticationMethods publickey;
• PAM не разрешает парольную аутентификацию;
• пароль истёк/заблокирован;
• СЗИ требует токен/2FA.

---

---

---

5.6. SSH не принимает ключ, но пароль работает

Смотрим:

ls -ld /home/username /home/username/.ssh /home/username/.ssh/authorized_keys
namei -l /home/username/.ssh/authorized_keys

Правильные базовые права обычно такие:

chmod 750 /home/username
chmod 700 /home/username/.ssh
chmod 600 /home/username/.ssh/authorized_keys
chown -R username:username /home/username/.ssh

Также проверьте:

grep -Ei '^(AuthorizedKeysFile|AuthorizedKeysCommand|AuthorizedKeysCommandUser|StrictModes)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/* 2>/dev/null

---

5.7. SSH не работает только с одного адреса

Проверяем:

• AllowUsers user@addr;
• Match Address;
• firewall;
• /etc/hosts.deny;
• fail2ban;
• сетевые правила СЗИ;
• pam_access.

grep -vE '^\s*(#|$)' /etc/hosts.deny /etc/hosts.allow 2>/dev/null
fail2ban-client status sshd 2>/dev/null || true
iptables -S INPUT | grep -E '22|DROP|REJECT' || true
nft list ruleset 2>/dev/null | grep -E '22|drop|reject' || true

5.8. su не работает от root

Если вы уже администратор/root, но su - username не работает, смотрите:

1. Есть ли в /etc/pam.d/su строка:

auth sufficient pam_rootok.so

Если её нет или она после других auth-правил, su от root может вести себя некорректно.

2. Не включён ли pam_wheel.so без необходимости:

grep -n 'pam_wheel' /etc/pam.d/su

3. Не снят ли setuid:

SU_BIN=$(readlink -f "$(command -v su)")
ls -l "$SU_BIN"

Должен быть примерно:

-rwsr-xr-x 1 root root ... /bin/su

Если нет и это не сделано намеренно политикой:

chmod u+s "$SU_BIN"

4. Не смонтированы ли разделы с nosuid:

findmnt -no OPTIONS / /usr

Если / или /usr имеют nosuid, setuid-бинарники не будут работать.

---

5.9. su не работает от обычного пользователя

Это может быть не ошибкой, а политикой:

• нужен sudo;
• нужен членство в wheel;
• root-пароль неизвестен;
• включён запрет su.

Проверка:

grep -n 'pam_wheel' /etc/pam.d/su
getent group wheel
id username

Если в вашей конфигурации действительно требуется wheel, добавьте пользователя:

usermod -aG wheel username

Но в ряде систем вместо этого рекомендуется использовать sudo.

---

5.10. Fly не запускается: возврат в дисплейный менеджер

Если после ввода пароля графическая сессия сразу завершает работу и возвращает к менеджеру входа, смотрите:

tail -n 200 ~/.xsession-errors
journalctl _UID=$(id -u username) -b --no-pager | tail -n 200
journalctl -u display-manager -b --no-pager | tail -n 200
grep -E '\(EE\)|\(WW\)' /var/log/Xorg.0.log 2>/dev/null
grep -E '\(EE\)|\(WW\)' ~/.local/share/xorg/Xorg.0.log 2>/dev/null

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

• сломан сессионный скрипт;
• отсутствует исполняемый файл Fly;
• блокировка исполнения политикой СЗИ;
• нет dbus/systemd-logind;
• не создан /run/user/UID;
• повреждён профиль пользователя;
• нет прав на домашний каталог;
• не хватает ресурсов;
• графический бинарник падает из-за LD_PRELOAD или модуля СЗИ.

5.11. Дисплейный менеджер вообще не стартует

Проверка:

systemctl get-default
systemctl status display-manager --no-pager
cat /etc/X11/default-display-manager 2>/dev/null
ls -l "$(cat /etc/X11/default-display-manager 2>/dev/null)" 2>/dev/null
systemctl cat display-manager.service | grep -E 'ExecStart|User|Protect|dallas|dlk'

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

• default-display-manager указывает на несуществующий бинарник;
• пакет дисплейного менеджера удалён или сломан;
• служба замаскирована;
• графическая цель отключена:

systemctl get-default

---

---

Если должно быть графическое окружение:

systemctl get-default | grep graphical.target || echo "Default target is not graphical"

Установка графической цели по умолчанию выполняется так, но только если это разрешено:

systemctl set-default graphical.target

---

Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.

---