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

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

6. Основные причины и как их проверять

6.1. Учётная запись заблокирована или пароль истёк

Проверка:

U=username
passwd -S "$U"
chage -l "$U"
faillock --user "$U" 2>/dev/null || pam_tally2 --user "$U" 2>/dev/null || true
getent shadow "$U" | awk -F: '{print substr($2,1,1)}'

Признаки:

• пароль начинается с !;
• Password expired;
• Password must be changed;
• Account expires;
• faillock показывает много неудачных попыток.

---

---

Исправление:

# Сбросить пароль
passwd "$U"

# Если нужно убрать дату истечения действия учётной записи
chage -E -1 "$U"

# Сбросить faillock, если используется
faillock --user "$U" --reset 2>/dev/null || true

# Для старых систем с pam_tally2
pam_tally2 --user "$U" --reset 2>/dev/null || true

Если пароль истёк, а дисплейный менеджер не умеет корректно показывать смену пароля, пользователь не сможет войти графически. Смените пароль через консоль.

---

6.2. Есть /etc/nologin или /run/nologin

Проверка:

ls -l /etc/nologin /run/nologin 2>/dev/null
cat /etc/nologin 2>/dev/null
cat /run/nologin 2>/dev/null

Если система не находится в режиме планового обслуживания и файл остался случайно:

mv /etc/nologin /etc/nologin.bak 2>/dev/null
mv /run/nologin /run/nologin.bak 2>/dev/null

---

6.3. Повреждён или изменён PAM

Это самая частая причина, если одновременно ломаются несколько способов входа.

Проверка:

ls -l /etc/pam.d
ls -l /etc/pam.d/common-*
ls -l /usr/share/pam-configs
grep -R -Ei 'dallas|dlk' /etc/pam.d /usr/share/pam-configs /etc/security 2>/dev/null

Проверка синтаксиса и подозрительных строк:

grep -n . /etc/pam.d/common-auth
grep -n . /etc/pam.d/common-account
grep -n . /etc/pam.d/common-session

Что искать:

• модуль СЗИ, которого нет на диске;
• auth requisite pam_deny.so раньше нужного модуля;
• отсутствие pam_unix.so;
• отсутствие pam_systemd.so в сессии;
• дублирующие или конфликтующие строки;
• pam_exec.so, вызывающий скрипт СЗИ;
• неверный порядок required, requisite, sufficient.

Если используется pam-auth-update, посмотрите подключённые конфиги:

ls -l /usr/share/pam-configs

Если там есть файл СЗИ и после его появления начались проблемы, можно временно вынести его и пересобрать конфигурацию:

mkdir -p /root/disabled-pam-configs
mv /usr/share/pam-configs/*dallas* /root/disabled-pam-configs/ 2>/dev/null
mv /usr/share/pam-configs/*dlk* /root/disabled-pam-configs/ 2>/dev/null

pam-auth-update --package

Внимание: делайте это только при наличии резервной копии и консольного доступа.

Если модуль прописан напрямую в /etc/pam.d/common-auth, common-account, common-session, найдите строки и временно закомментируйте их вручную:

grep -nE 'dallas|dlk' /etc/pam.d/common-auth /etc/pam.d/common-account /etc/pam.d/common-session /etc/pam.d/sshd /etc/pam.d/su

Затем отредактируйте файлы и поставьте # перед подозрительными строками СЗИ.

Перед любыми правками сделайте резервную копию:

TS=$(date +%Y%m%d-%H%M%S)
mkdir -p /root/backup-$TS
cp -a /etc/pam.d /root/backup-$TS/
cp -a /etc/security /root/backup-$TS/ 2>/dev/null
cp -a /etc/ssh /root/backup-$TS/
cp -a /etc/X11 /root/backup-$TS/ 2>/dev/null
cp -a /etc/profile.d /root/backup-$TS/ 2>/dev/null
cp -a /etc/environment /root/backup-$TS/ 2>/dev/null

---

6.4. Отсутствует или сломан модуль PAM

Проверка:

find /lib/*/security /usr/lib/*/security -iname '*dallas*' -o -iname '*dlk*' 2>/dev/null
for f in /lib/*/security/pam_*.so; do
  ldd "$f" 2>/dev/null | grep -i 'not found' && echo "Broken dependencies: $f"
done

Если в PAM есть строка вида:

auth required pam_dallaslock.so

а файла pam_dallaslock.so нет, аутентификация будет ломаться.

Варианты:

1. Переустановить/починить компонент СЗИ.
2. Временно закомментировать строку для диагностики.
3. Восстановить модуль из дистрибутива СЗИ.

---

6.5. Нет pam_systemd или сломан logind/dbus

Для Fly и нормальных пользовательских сеансов часто критичны:

• systemd-logind;
• dbus;
• pam_systemd;
• /run/user/UID;
• пользовательская шина D-Bus.

---

---

Проверка:

systemctl status systemd-logind --no-pager
systemctl status dbus dbus.socket --no-pager
grep pam_systemd /etc/pam.d/common-session
ls -l /lib/*/security/pam_systemd.so

Проверка пользовательской среды:

U=username
UIDU=$(id -u "$U")
runuser -u "$U" -- env | grep -E 'XDG_RUNTIME_DIR|DBUS_SESSION_BUS_ADDRESS|DISPLAY|XAUTHORITY'
ls -ld /run/user/"$UIDU" 2>/dev/null
loginctl list-users
loginctl user-status "$U" 2>/dev/null || true

Если /run/user/UID не создаётся, проверьте:

• наличие libpam-systemd;
• наличие pam_systemd.so в /etc/pam.d/common-session;
• работу systemd-logind;
• работу dbus.

Пакеты, которые могут быть важны:

dpkg -l | grep -Ei 'libpam-systemd|dbus|dbus-user-session|dbus-x11'

---

6.6. SSH: служба, конфиг, права, ключи

Проверка службы

systemctl status ssh sshd --no-pager || true
systemctl is-enabled ssh sshd 2>/dev/null || true
systemctl is-active ssh sshd 2>/dev/null || true
ss -ltnp | grep ':22'

Если служба не запущена и это не запрещено политикой:

systemctl start ssh
systemctl enable ssh

Если служба в masked:

systemctl list-unit-files | grep -Ei 'ssh.*masked'

Размаскировка только при наличии оснований:

systemctl unmask ssh.service

Проверка конфигурации

/usr/sbin/sshd -t

Если есть ошибка, читаем её и исправляем.

Типовые файлы:

ls -l /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
grep -R . /etc/ssh/sshd_config.d/ 2>/dev/null

Привилегированный каталог и ключи

Иногда помогает:

mkdir -p /run/sshd
chmod 0755 /run/sshd

Проверка хост-ключей:

ls -l /etc/ssh/ssh_host_*

Если ключи отсутствуют:

ssh-keygen -A

или:

dpkg-reconfigure openssh-server

Права на приватные хост-ключи обычно должны быть строгими:

chmod 600 /etc/ssh/ssh_host_*_key

Права пользователя и authorized_keys

U=username
ls -ld /home/$U
ls -ld /home/$U/.ssh
ls -l /home/$U/.ssh/authorized_keys
namei -l /home/$U/.ssh/authorized_keys

Исправление базовых прав:

chown -R "$U":"$(id -gn "$U")" /home/"$U"/.ssh
chmod 700 /home/"$U"/.ssh
chmod 600 /home/"$U"/.ssh/authorized_keys
chmod g-w /home/"$U"

Диагностика с подробным логом

На сервере можно временно поднять отладочный sshd на отдельном порту:

/usr/sbin/sshd -ddd -p 2222 -o ListenAddress=127.0.0.1 -o PermitRootLogin=no

В отдельном терминале:

ssh -vvv -p 2222 username@127.0.0.1

Вывод sshd -ddd часто сразу показывает, где именно отказ.

Диагностический запуск с UsePAM=no можно использовать только как временный тест, чтобы понять, виноват ли PAM:

/usr/sbin/sshd -ddd -p 2222 -o ListenAddress=127.0.0.1 -o UsePAM=no -o PermitRootLogin=no

Если с UsePAM=no вход проходит, а с UsePAM=yes нет — проблема в PAM или в сессионных модулях.

---

6.7. Ошибки алгоритмов и старых клиентов

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

no matching key exchange method
no matching host key type
no matching cipher
Permission denied (publickey)

Проверка:

/usr/sbin/sshd -T | grep -Ei 'kexalgorithms|ciphers|macs|hostkeyalgorithms|pubkeyacceptedalgorithms'

Если клиент старый, лучше обновить клиент. Включать старые алгоритмы стоит только по согласованию с ИБ.

---

6.8. TCP Wrappers, fail2ban, сетевой фильтр

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
ufw status verbose 2>/dev/null || true

---

---

Если порт 22 закрыт, нужно понять, кто именно его закрыл:

• штатный файрвол;
• сетевой модуль СЗИ;
• политика централизованного управления;
• случайно применённое правило.

---

6.9. su: pam_rootok, pam_wheel, setuid

pam_rootok

В /etc/pam.d/su обычно первой важной строкой должно быть:

auth sufficient pam_rootok.so

Проверка:

head -n 10 /etc/pam.d/su
grep -n 'pam_rootok' /etc/pam.d/su

Если строки нет или она ниже других обязательных правил, su от root может запрашивать пароль или завершаться ошибкой.

pam_wheel

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

Если включено:

auth required pam_wheel.so

то su может быть разрешён только пользователям из группы wheel.

Проверка:

getent group wheel
id username

Добавить пользователя:

usermod -aG wheel username

setuid и nosuid

SU_BIN=$(readlink -f "$(command -v su)")
ls -l "$SU_BIN"
findmnt -no OPTIONS / /usr

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

chmod u+s "$SU_BIN"

Если / или /usr смонтированы с nosuid, setuid-механизм работать не будет.

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

Проверка пакетов

dpkg -l | grep -Ei 'fly|xserver-xorg|dbus|lightdm|gdm|sddm|x11-xserver-utils|xauth'

Если видно, что пакеты удалены или зависимости сломаны:

dpkg --audit
dpkg --configure -a
apt-get check
apt-get -s -f install

Сначала используйте -s — симуляцию, чтобы понять, не собирается ли пакетный менеджер удалить что-то важное.

Проверка сессии

ls -l /usr/share/xsessions/
grep -E 'Exec|TryExec' /usr/share/xsessions/*.desktop 2>/dev/null
update-alternatives --get-selections | grep -Ei 'x-session-manager|x-window-manager|x-display-manager' || true

Если файл сессии Fly отсутствует или Exec указывает на несуществующий файл, окружение не запустится.

Логи

tail -n 200 ~/.xsession-errors
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
journalctl -u display-manager -b --no-pager | tail -n 200

Типичные ошибки в логах

Сообщение/признак	Возможная причина
cannot open display	DISPLAY/XAUTHORITY, X-сервер не запущен
Failed to connect to D-Bus	dbus/user-session/logind
Segmentation fault	падение компонента, конфликтная библиотека, модуль СЗИ
Permission denied	MAC, права, блокировка исполнения
no screens found	драйвер/модуль GPU/Xorg
Failed to load module	отсутствует модуль Xorg
Could not load the Qt platform plugin	Qt-зависимости/переменная QT_QPA_PLATFORM
No such file or directory для fly-бинарника	пакет удалён или путь изменён

---

6.11. Проблемы с окружением и LD_PRELOAD

Это особенно важно, если после установки СЗИ ломаются сразу разные программы.

Проверка глобальных мест:

cat /etc/ld.so.preload 2>/dev/null
grep -R -E 'LD_PRELOAD|LD_LIBRARY_PATH|GTK_MODULES|QT_QPA_PLATFORM' /etc/environment /etc/profile.d /etc/X11/Xsession.d /etc/systemd/system.conf /etc/systemd/user.conf 2>/dev/null

Проверка переменных пользователя:

U=username
runuser -u "$U" -- env | grep -E 'LD_PRELOAD|LD_LIBRARY_PATH|GTK_MODULES|QT_QPA_PLATFORM|DISPLAY|XAUTHORITY|XDG_RUNTIME_DIR|DBUS_SESSION_BUS_ADDRESS'

Если видите подозрительный LD_PRELOAD, указывающий на библиотеку СЗИ, а библиотеки нет или она вызывает сбои, это надо временно убирать для диагностики.

Резервная копия:

[ -f /etc/ld.so.preload ] && cp /etc/ld.so.preload /root/ld.so.preload.bak

Очистка только если вы понимаете, что делаете:

[ -f /etc/ld.so.preload ] && : > /etc/ld.so.preload

---

---

6.12. Автозапуск и скрипты входа

Скрипты, которые могут ломать вход:

ls -l /etc/profile.d/
ls -l /etc/X11/Xsession.d/
ls -l /etc/X11/xinit/xinitrc.d/ 2>/dev/null
ls -l /etc/xdg/autostart/ | grep -Ei 'dallas|dlk' || true
ls -l ~/.config/autostart/ 2>/dev/null

Проверка синтаксиса:

for f in /etc/profile.d/*.sh; do bash -n "$f" || echo "Syntax error in: $f"; done

Если есть скрипт СЗИ, который завершает сеанс, его нужно анализировать:

grep -R -Ei 'exit|return' /etc/profile.d/*dallas* /etc/X11/Xsession.d/*dallas* 2>/dev/null

6.13. Права на домашний каталог

Если пользователь не может писать в домашний каталог, Fly может не стартовать.

U=username
ls -ld /home/$U
ls -ld /home/$U/.config /home/$U/.cache /home/$U/.local 2>/dev/null
namei -l /home/$U

Базовое восстановление прав:

chown -R "$U":"$(id -gn "$U")" /home/"$U"
chmod 750 /home/"$U"

Если пользователь ранее запускал графические программы через sudo, владельцем файлов в ~/.config может оказаться root. Это частая причина падения окружения.

6.14. Повреждённые пользовательские конфиги

Можно временно переместить конфиги в резерв:

sudo -u username bash -lc '
mkdir -p ~/fly-config-backup
mv ~/.config/fly* ~/fly-config-backup/ 2>/dev/null
mv ~/.config/Fly* ~/fly-config-backup/ 2>/dev/null
mv ~/.config/autostart ~/fly-config-backup/ 2>/dev/null
mv ~/.Xauthority ~/fly-config-backup/ 2>/dev/null
mv ~/.ICEauthority ~/fly-config-backup/ 2>/dev/null
mv ~/.xsession ~/fly-config-backup/ 2>/dev/null
'

После этого попробуйте войти снова. Если проблема исчезла — значит, дело в пользовательских настройках.

6.15. Ресурсные ограничения

Проверка:

grep -R . /etc/security/limits.conf /etc/security/limits.d 2>/dev/null
runuser -u username -- bash -lc 'ulimit -a'
loginctl list-sessions

На что смотреть:

• maxlogins;
• nofile;
• nproc;
• as;
• stack;
• memlock.

Если maxlogins равен 1 и где-то остался зависший сеанс:

loginctl list-sessions
loginctl terminate-user username

6.16. Мандатные метки и механизмы защиты Astra

В редакциях Astra с усиленной защитой возможны:

• мандатный контроль доступа;
• контроль целостности;
• замкнутая программная среда;
• ограничения на исполнение;
• несовместимость уровней доступа пользователя и объекта.

Проверяйте системные сообщения:

dmesg -T | grep -Ei 'parsec|apparmor|audit|denied|blocked|integrity|ima|evm' | tail -n 100
journalctl -k -b | grep -Ei 'denied|blocked|parsec|apparmor|audit' | tail -n 100

Если видите отказы для:

• /usr/sbin/sshd;
• /bin/su;
• /usr/bin/fly*;
• /usr/lib/xorg/Xorg;
• dbus;
• домашних файлов;

значит, проблема может быть не в классическом Unix-доступе, а в политике безопасности.

---

В таком случае:

1. Не меняйте метки вслепую.
2. Проверьте документацию вашей версии.
3. Проверьте, разрешено ли выполнение этих компонентов политикой СЗИ и политикой ОС.
4. При необходимости скорректируйте правила через штатный механизм защиты.

---

6.17. Если используется доменная аутентификация

Если ломаются только доменные пользователи:

systemctl status sssd --no-pager
id username
getent passwd username
timeout 5 getent passwd username; echo rc=$?
sss_cache -E 2>/dev/null || true
tail -n 200 /var/log/sssd/sssd.log 2>/dev/null
ls -l /var/log/sssd/ 2>/dev/null

Проверьте:

• время на сервере;
• Kerberos;
• DNS;
• LDAP;
• nsswitch.conf;
• доступность контроллера домена;
• срок действия пароля/учётки в домене.

Если getent зависает, смотрите /etc/nsswitch.conf и порядок sss/files.

---

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

---