02-user — пользователь для деплоя

Создаёт непривилегированного пользователя deploy, раскладывает SSH-ключи, выдаёт passwordless sudo и стандартные каталоги. 🔒 обязательный.

Зачем нужен #

Работать на сервере под root — плохая практика: любая ошибка или скомпрометированный процесс сразу получают полный контроль. Этот модуль создаёт отдельного пользователя (по умолчанию deploy), под которым живут приложения, docker-контейнеры и деплой-скрипты. Он же — путь восстановления доступа, если прямой вход root по SSH будет отключён модулем безопасности.

Пользователь получает sudo (право выполнять команды от имени root) через группу sudo (на Debian/Ubuntu) или wheel (на RHEL/SUSE). Причём sudo настраивается без пароля (NOPASSWD) — это осознанное решение: сам mitdev перезапускает привилегированные команды через sudo -n (без запроса пароля), и на серверах с входом только по ключу пароль от unix-аккаунта не добавляет реальной защиты (SSH-ключ и так эквивалентен root-доступу), зато его отсутствие ломало бы всю автоматизацию.

Без этого модуля не было бы безопасного «рабочего» аккаунта, authorized_keys не были бы разложены, а команды mitdev, требующие root, не работали бы в неинтерактивном режиме. Этого модуля достаточно, чтобы зайти на сервер по ключу под deploy и управлять им; усиление самого SSH делает модуль 03-security.

Когда включать и когда не нужен #

• Всегда включён — обязательный модуль.
• Идемпотентен: если пользователь уже существует, модуль не пересоздаёт его, а лишь обновляет настройки (группы, sudo, ключи, каталоги). Повторный запуск безопасен.
• Пароль устанавливается только если задан DEPLOY_PASSWORD (в мастере можно оставить пустым — тогда пароль не меняется).

Зависимости и требования #

• Логически идёт после 01-system (базовые пакеты, openssl).
• Генерация SSH-ключей (если включена) требует ssh-keygen; при его отсутствии установщик доустанавливает openssh-client.
• Мультидистро: административная группа определяется автоматически — sudo на Debian/Ubuntu, wheel на RHEL/SUSE/Arch; если группы нет, она создаётся.
• Проверка правила sudoers выполняется через visudo -c — при непрохождении проверки правило не применяется (чтобы не сломать sudo).

Что именно делает #

Пошагово, в порядке module_install (имя пользователя — из DEPLOY_USER):

1. Создаёт пользователя useradd --create-home --shell /bin/bash <user> (если его ещё нет) и регистрирует откат userdel -r.
2. Пароль — если задан DEPLOY_PASSWORD, устанавливает его через chpasswd. Значение пароля в лог не пишется.
3. Административная группа — определяет sudo/wheel, создаёт при отсутствии и добавляет пользователя: usermod -aG <группа> <user>.
4. Passwordless sudo — пишет файл /etc/sudoers.d/90-mitdev-<user> с правилом <user> ALL=(ALL) NOPASSWD:ALL, проверяет его visudo -c и только после успешной проверки применяет. Регистрирует откат.
5. SSH-ключи (authorized_keys — файл со списком публичных ключей, которым разрешён вход): раскладывает ключ root в /root/.ssh/authorized_keys (из ROOT_SSH_KEY) и ключи deploy в /home/<user>/.ssh/authorized_keys (из DEPLOY_SSH_KEYS/DEPLOY_SSH_KEY). Каталог .ssh создаётся с правами 700, файл — 600, дубли ключей не добавляются.
6. Каталоги — создаёт стандартную структуру из DEPLOY_HOME_DIRS (apps docker logs backups scripts) с правами 750, владелец — пользователь; домашний каталог тоже 750.
7. Отмечает модуль выполненным (state_mark).

Сами SSH-ключи (пары Ed25519) генерирует не модуль, а мастер установки (install.sh) до его запуска — см. раздел «Генерация ключей».

Генерация ключей Ed25519 и Termius #

Если GENERATE_SSH_KEYS_DEFAULT=yes (по умолчанию), мастер предлагает сгенерировать свежие пары ключей Ed25519 (современный, короткий и быстрый тип SSH-ключей) для root и для deploy:

• Приватные ключи хранятся только на сервере, в каталоге GENERATED_SSH_KEY_DIR = /root/.mitdev-keys/ (права 700), файлы вида <имя>_ed25519 (600) и <имя>_ed25519.pub (644).
• Публичные части сразу попадают в authorized_keys соответствующих аккаунтов этим модулем.
• Пути к ключам дублируются в файл учётных данных /root/.mitdev-credentials (только root, 600).

Чтобы забрать приватный ключ для клиента (например, Termius или другого SSH-приложения):

sudo mitdev ssh-key                 # статус: какие ключи есть и где лежат
sudo mitdev ssh-key show deploy     # печатает приватный ключ deploy (скопировать в Termius)
sudo mitdev ssh-key show root       # приватный ключ root
sudo mitdev ssh-key pub deploy      # публичный ключ
sudo mitdev ssh-key path deploy     # путь к файлу ключа

В Termius: Keychain → New Key → вставить содержимое приватного ключа. Приватный ключ — это доступ к серверу; не пересылайте его по незащищённым каналам.

Файлы, службы и порты #

Служб и портов модуль не создаёт.

Настройка #

Мастер установки спрашивает: имя пользователя, пароль (можно пусто), публичный SSH-ключ (можно пусто), нужно ли генерировать ключи для Termius.

Как переопределить настройки #

1. Экспорт перед установкой (-E сохраняет переменные при sudo):

   DEPLOY_USER_DEFAULT=web DEPLOY_HOME_DIRS="apps logs releases" sudo -E ./install.sh
   

2. Правка config/defaults.conf — измените DEPLOY_USER_DEFAULT, DEPLOY_HOME_DIRS, GENERATE_SSH_KEYS_DEFAULT, GENERATED_SSH_KEY_DIR.
3. Ответы в мастере установки — имя пользователя, пароль, свой публичный ключ и согласие на генерацию ключей задаются интерактивно при запуске без экспортов.

Проверка, что всё работает #

module_verify считает модуль успешным, если пользователь существует и состоит в административной группе (sudo/wheel).

Ручные проверки:

id deploy                                   # должен показать группу sudo (или wheel)
sudo -l -U deploy                           # правило (ALL) NOPASSWD: ALL
ls -la /home/deploy/.ssh/authorized_keys    # права 600, ключи внутри
ls /home/deploy                             # apps docker logs backups scripts
sudo mitdev ssh-key                         # статус сгенерированных ключей

Проверка входа по ключу (с локальной машины, не закрывая текущую сессию):

ssh -i /путь/к/приватному/ключу deploy@<адрес-сервера>

Типовые задачи #

• Забрать приватный ключ для Termius/клиента:

  sudo mitdev ssh-key show deploy
  

• Добавить свой публичный ключ существующему deploy:

  sudo -u deploy tee -a /home/deploy/.ssh/authorized_keys < ~/mykey.pub
  

• Сменить пароль пользователя:

  sudo passwd deploy
  

• Проверить, что sudo работает без пароля:

  sudo -n -u deploy sudo -n true && echo OK
  

• Пересоздать/обновить каталоги и настройки — просто перезапустите установку: модуль идемпотентен.

Частые ошибки #

Безопасность и продакшен #

Модуль уже закрывает: отдельный непривилегированный аккаунт вместо root, строгие права на .ssh и authorized_keys, безопасное хранение приватных ключей только под root (700/600), проверку правила sudoers перед применением.

Остаётся на клиенте: беречь приватные ключи (не хранить в общих чатах/репозиториях); при желании сузить sudo вручную (по умолчанию NOPASSWD:ALL — см. объяснение в разделе «Зачем нужен»); включить отключение root-входа и паролей в модуле 03-security.

Откат и удаление #

• Авто-откат при падении установки (module_rollback): удаляет только что созданного пользователя вместе с его домашним каталогом (userdel -r).
• mitdev remove user: удаляет пользователя, но по умолчанию сохраняет домашний каталог (/home/<user> — там apps, docker, backups: данные клиента). Перед удалением завершает процессы пользователя (pkill).
• mitdev remove user --purge: удаляет пользователя и его домашний каталог целиком (необратимо).

См. также #

• ../COMMANDS.md — mitdev ssh-key, mitdev remove.
• ../CONFIGURATION.md — переменные deploy и SSH-ключей.
• 03-security.md — усиление SSH (отключение пароля/root-входа).
• 01-system.md — базовая подготовка, выполняется раньше.