Автоматизация Bash: безопасное использование паролей

женщина-инженер пишет bash-скрипт в Linux

Bash-скрипты — важная часть работы системного администратора. Они позволяют автоматизировать рутинные и критичные задачи, выполнять их без участия человека и интегрироваться в планировщики задач (cron). Одна из распространённых проблем — автоматизация действий, которые требуют пароля. В этой статье показано несколько безопасных подходов: от простого до рекомендованного.

Что мы настроим

Простой Bash-скрипт для резервного копирования домашней папки на удалённый сервер с помощью rsync.
Вариант с sshpass (быстро, но менее безопасно).
Безопасный вариант: пароль зашифрован GnuPG и используется временный файл с ограниченными правами.
Рекомендуемый способ: SSH-ключи и ssh-agent.

1. Простой скрипт для резервного копирования

Создайте файл в домашней папке, например backup_home.sh, и сделайте его исполняемым:

#!/bin/bash
# Копирование данных на удалённый сервер
rsync -av --mkpath /home/john user_name@remote_server:/home/Backup

Замените /home/john на путь вашей домашней папки.
Замените user_name@remote_server на имя пользователя и адрес удалённого хоста.

Сохраните файл и сделайте его исполняемым:

sudo chmod 755 ~/backup_home.sh

Выполнение:

./backup_home.sh

При стандартной настройке rsync по SSH вам будет предложено ввести пароль удалённого пользователя — это не подходит для фоновых задач.

Важно: опция –mkpath добавляет создание пути на удалённой стороне. Если ваша версия rsync её не поддерживает, создайте директорию вручную или используйте ssh для создания каталога перед синхронизацией.

2. Быстрое решение: sshpass (не рекомендуется для продакшена)

sshpass позволяет передавать пароль неинтерактивно. Установите его на Debian-подобных дистрибутивах:

sudo apt update && sudo apt install sshpass

На RHEL/Fedora:

sudo dnf install sshpass

Пример (небезопасный — пароль в явном виде):

sshpass -p "yourpassword" rsync -av --mkpath /home/john user_name@remote_server:/home/Backup

Недостатки:

Пароль виден в командной строке (ps) и в истории.
Скрипт с открытым паролем опасен при утечке.

3. Шифрование пароля с GnuPG и безопасная передача в sshpass

GnuPG (gpg) часто уже установлен в Linux. Если нет — установите через менеджер пакетов.

Создайте скрытый файл с паролем и зашифруйте его:

# Создаём скрытый файл в домашней папке
echo "yourpassword" > ~/.secrets
chmod 600 ~/.secrets
# Симметрическое шифрование (будет запрошена фраза-пароль для открытия файла)
gpg -c ~/.secrets
# После этого безопасно удалите исходный незашифрованный файл
shred -u ~/.secrets
# Получится ~/.secrets.gpg

Используйте зашифрованный файл в скрипте, извлекая пароль во временный защищённый файл, который сразу удаляется качественным удалением.

Пример скрипта, безопаснее чем хранить пароль в явном виде:

#!/bin/bash
set -euo pipefail
# Настройки
ENCRYPTED_FILE="$HOME/.secrets.gpg"
SRC_DIR="/home/john"
DEST="user_name@remote_server:/home/Backup"

# Создаём безопасный временный файл
TMPPW=$(mktemp)
chmod 600 "$TMPPW"
# Расшифровываем пароль в этот файл
gpg -dq "$ENCRYPTED_FILE" > "$TMPPW"
# Используем sshpass с опцией -f (чтение пароля из файла)
sshpass -f "$TMPPW" rsync -av --mkpath "$SRC_DIR" "$DEST"
# Удаляем и перезаписываем временный файл
shred -u "$TMPPW"

Пояснения:

mktemp создаёт уникальный файл с безопасными правами.
chmod 600 делает файл доступным только владельцу.
shred -u пытается перезаписать и удалить файл.
gpg -dq выводит содержимое в stdout без лишних сообщений.

Примечание: процесс с временным файлом — более безопасен, чем хранение пароля в открытом виде, но всё ещё требует аккуратности (права на папки, мониторинг журналов и т.д.).

4. Рекомендуемый вариант: SSH-ключи (без пароля для автоматизации)

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

Генерация ключа (на машине-источнике):

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_backup -C "backup key" -N ""
# Пустая фраза-пароль позволяет автозапуск без ввода пароля; для большей безопасности можно использовать ключ с фразой и ssh-agent.
ssh-copy-id -i ~/.ssh/id_ed25519_backup.pub user_name@remote_server

В скрипте указывайте ключ явно или используйте ssh-agent:

RSYNC_RSH="ssh -i $HOME/.ssh/id_ed25519_backup -o StrictHostKeyChecking=accept-new"
RSYNC_OPTIONS="-av"
RSYNC_RSYNC="$RSYNC_RSH rsync"
rsync -e "$RSYNC_RSH" $RSYNC_OPTIONS /home/john user_name@remote_server:/home/Backup

Преимущества SSH-ключей:

Нет необходимости хранить или передавать пароли.
Более лёгкое управление доступом и отзыв ключей.
Поддерживается ssh-agent для безопасного хранения приватных ключей в памяти.

5. Интеграция с cron

Добавьте задание в crontab для регулярного резервного копирования. Откройте редактор crontab:

crontab -e

Пример: ежедневный запуск в 02:30

30 2 * * * /home/youruser/backup_home.sh >> /var/log/backup_home.log 2>&1

Советы:

Перенаправляйте stdout и stderr в лог-файл с ротацией (logrotate).
Проверяйте права на скрипты и файлы с паролями.

6. Права доступа и безопасность файлов

Скрипт: chmod 700 или 750 в зависимости от доверия к группе.
Файлы с секретами: chmod 600; храните их в домашней папке пользователя, не в общих каталогах.
Логи: избегайте записи паролей в лог-файлы.
Менеджеры секретов (Vault, Hashicorp, AWS KMS) предпочтительнее для корпоративной среды.

7. Тесты и критерии приёмки

Критерии приёмки для автоматизированного бэкапа:

Скрипт выполняется без запроса пароля при запуске от запланированного пользователя.
rsync завершился с кодом 0 (успех) и без критичных ошибок.
Файлы появились на целевой стороне в ожидаемой структуре.
Логи не содержат раскрытых паролей.
Временный файл с паролем удалён и не доступен другим пользователям.

Простейшие тесты:

Локальный запуск вручную и проверка кода возврата: echo $?
Проверка целостности передачи (rsync –checksum или сравнение контрольных сумм).
Запуск crontab и проверка /var/log/backup_home.log

8. Альтернативные подходы и когда они подходят

SSH-ключи: лучший выбор для постоянного автоматизированного доступа.
sshpass + GnuPG: подходит для быстрых сценариев и скриптов, где нельзя изменить удалённый сервер.
Менеджеры секретов (Vault/Secret Manager): для крупных инфраструктур и распределённых команд.

Контрпример — когда не использовать sshpass:

В средах с высокой безопасностью и аудитом, где политика запрещает хранение паролей локально.

9. Дополнительные рекомендации и чеклист по развёртыванию

Роль: Системный администратор

Проверить версию rsync и опцию –mkpath.
Настроить SSH-ключи и протестировать вход без пароля.
Если используется GPG: проверить политику управления фразой-паролем.
Настроить логирование и ротацию логов.
Ограничить права на скрипт и файлы с секретами.
Добавить оповещение при неудачном бэкапе (email или системный алерт).

10. Пример рабочего плейбука (SOP) для развёртывания

На машине-источнике: сгенерировать SSH-ключ или подготовить .secrets.gpg.
На целевой машине: добавить публичный ключ в ~user/.ssh/authorized_keys или согласовать пароль.
Подготовить и протестировать скрипт вручную.
Настроить cron и логирование.
Автоматизировать мониторинг успешности (exit code, уведомления).

11. Небольшая диаграмма принятия решения

flowchart TD
  A[Нужна автоматизация] --> B{Можно ли использовать SSH-ключи?}
  B -- Да --> C[Настроить ключи и ssh-agent]
  B -- Нет --> D{Можно ли установить gpg и sshpass?}
  D -- Да --> E[Зашифровать пароль gpg, использовать временный файл]
  D -- Нет --> F[Рассмотреть менеджер секретов или ручной сценарий]
  C --> G[Внедрить cron и мониторинг]
  E --> G
  F --> G

Итог и рекомендации

Лучший подход для автоматизации резервного копирования — SSH-ключи. Это безопасно и просто в сопровождении.
Если ключи невозможны, храните пароль зашифрованным (GnuPG) и используйте временный файл с ограниченными правами для передачи в sshpass.
Никогда не храните пароли в скриптах в открытом виде и не добавляйте их в логи.

Короткая проверка перед выводом в продакшен: