Руководство администратора

Практическое руководство по экранам ssh-access-tui и типовым сценариям. Архитектурные решения и модель угроз — в ARCHITECTURE.md.

Запуск

sudo ssh-access-tui

Требует root (создаёт/блокирует системных пользователей, правит authorized_keys). Инструмент рассчитан на одного администратора одновременно на хосте — если кто-то ещё уже открыл TUI, вторая сессия получит ошибку про занятую блокировку состояния (state.lock), а не молча перезапишет чужие изменения.

Навигация везде: стрелки/j/k — перемещение по списку, enter — выбрать/подтвердить, esc — назад, ctrl+c — выход в любой момент.

Главное меню

Пользователи        — создать / заблокировать / разблокировать / удалить
Группы и хосты       — какие внутренние хосты кому разрешены
Экспорт архивов      — сгенерировать ключи и .7z для доставки
Аудит / кто в сети   — активные сессии и журнал подключений
Выход

Сценарий 1: новый сотрудник, у которого уже есть роль/группа доступа

Обычно сначала настраивают группу (один раз), потом заводят пользователей в неё пачками.

Группы и хосты → n → ввести имя группы (например team-billing) → enter.
Выбрать группу → enter, попасть в список хостов группы (изначально пуст).
n → заполнить: имя хоста (короткий алиас, например db-prod-1), адрес (как виден с jump-хоста), порт, описание (необязательно) → tab между полями → enter сохранить. Повторить для каждого внутреннего хоста, который должен быть доступен этой группе.
esc дважды — назад в главное меню.
Пользователи → n → имя пользователя (латиницей, будущий Linux-логин) и комментарий (например ФИО) → enter.
Отметить space нужные группы (можно несколько — эффективный список хостов пользователя = объединение хостов всех отмеченных групп) → enter.

Это уже создаёт системный Linux-аккаунт (без пароля, без интерактивного шелла) и запись в состоянии. Ключ ещё не выдан — статус в списке пользователей покажет «ключ не выдан».

Экспорт архивов → отметить space только что созданного пользователя (или a — отметить всех, удобно при пакетном найме) → enter.
Инструмент сгенерирует ключ, пропишет permitopen= под текущие хосты группы, соберёт .7z и покажет один общий пароль на всю партию — он показывается один раз, запишите/скопируйте сразу.
Передайте каждому пользователю его архив (файл, путь показан на экране, лежит в export_dir) любым каналом, а пароль от архива — отдельным каналом (голосом, в личку) и по возможности не всем одним и тем же сообщением в общем чате.
Пользователь распаковывает архив на Windows по инструкции INSTRUCTIONS.txt внутри архива (она уже сгенерирована под его конкретные разрешённые хосты).

Сценарий 2: добавили новый разрешённый хост существующей группе

Группы и хосты → выбрать группу → enter.
n → заполнить новый хост → enter.

Это сразу обновляет permitopen= в authorized_keys всех активных пользователей этой группы — доступ появляется немедленно, без каких-либо действий на стороне пользователя. Клиентский конфиг пользователя (его ~/.ssh/config) при этом не обновляется автоматически — если хотите, чтобы у пользователя появился готовый алиас для нового хоста, а не только "голый" доступ, повторно прогоните его через Экспорт архивов (это заодно ротирует его ключ — считайте это плановой ротацией, не проблемой).

Удаление хоста из группы (d в списке хостов) действует так же немедленно и в обратную сторону.

Сценарий 3: сотрудник уволился

Пользователи → выбрать пользователя → l (заблокировать).

Это одновременно: блокирует пароль аккаунта, устанавливает немедленный срок истечения аккаунта (chage -E 1) и комментирует его ключ в authorized_keys — три независимых механизма, чтобы блокировка не зависела от одного из них. Статус в списке сменится на locked.

Если сотрудник вернулся — u (разблокировать) на том же пользователе: снимает блокировку аккаунта и восстанавливает его ключ в authorized_keys с текущими правами групп.

Полное удаление аккаунта (d) — необратимо (userdel -r, домашняя папка стирается), используйте для окончательного оффбординга, не для временной блокировки.

Сценарий 4: проверить, кто сейчас подключён / посмотреть историю

Аудит / кто в сети показывает:

«Сейчас в сети» — список активных SSH-сессий (по процессам sshd: user [priv], а не по who, потому что форвардинг-сессии без интерактивного терминала не создают обычных login-записей);
«Последние события» — журнал подключений/отключений, который в фоне собирает ssh-access-tui-audit.service из journalctl, независимо от ротации системного журнала.

r — обновить оба списка. Если журнал подключений пуст, хотя пользователи явно заходили — проверьте, что фоновый сервис запущен: systemctl status ssh-access-tui-audit.service.

Сценарий 5: перенос на новый хост / хост умер

См. подробности в ARCHITECTURE.md. Коротко: состояние (groups, users, публичные ключи, статусы) — git-репозиторий, бэкапится часовым таймером в удалённый git. На новом хосте: поднять ssh-access-tui, влить state.yaml из бэкапа, создать системные Linux-аккаунты для активных пользователей, выпустить им новые ключи через Экспорт архивов (старые приватные ключи специально нигде не хранятся — это не баг, см. архитектурный документ).

Что не делает эта версия (нужно руками)

Не удаляет .7z из export_dir после доставки — сделайте это сами, когда получатель подтвердил, что распаковал архив.
Не обновляет клиентский ~/.ssh/config пользователя автоматически при появлении нового хоста в его группе — только права доступа на сервере обновляются немедленно (см. сценарий 2).
Не поддерживает одновременную работу нескольких администраторов — рассчитан на одного за раз (см. «Конкурентность» в ARCHITECTURE.md).

9.8 KiB Raw Blame History Unescape Escape