Назад | Перейти на главную страницу

Rsync + безопасность аутентификации с открытым ключом

Я прочитал несколько статей о том, как автоматически создавать резервные копии файлов с помощью Rsync и аутентификации с открытым ключом. Все они очень похожи. Я только что закончил настраивать все, и все работает нормально, но ... Я только что нашел статью, в которой говорится, что это небезопасно. Я сделал следующее:

  1. На резервном сервере я сгенерировал открытый и закрытый ключи.
  2. Я скопировал открытый ключ в каталог удаленных (исходных) серверов: /var/sites/.ssh (файл authorized_keys). Каталог принадлежит "user12"
  3. Я добавил в файл authorized_keys следующее: from="BACKUP.SERVERS.IP.ADDRESS",command="/root/validate_rsync"
  4. Я создал файл / root / validate_rsync со следующим содержимым:

    #!/bin/sh
    echo $SSH_ORIGINAL_COMMAND >> /var/log/synchronize-log.log
    case "$SSH_ORIGINAL_COMMAND" in
    *\&*)
    echo "Rejected"
    ;;
    *\;*)
    echo "Rejected"
    ;;
    *\(*)
    echo "Rejected"
    ;;
    *\{*)
    echo "Rejected"
    ;;
    *\<*)
    echo "Rejected"
    ;;
    *\>*)
    echo "Rejected"
    ;;
    *\`*)
    echo "Rejected"
    ;;
    *\|*)
    echo "Rejected"
    ;;
    rsync\ --server*) 
    $SSH_ORIGINAL_COMMAND
    ;;
    *)
    echo "Rejected"
    ;;
    esac
    

Запускаю команду rsync:

rsync -avzp --del -e "ssh -p 2211" user12@ORIGINAL.SERVERS.IP:/var/sites/photos/ /var/sites/sync/photos

Я получил сообщение об ошибке: проблемы с разрешением файла /root/validate_rsync. Я переместил файл /root/validate_rsync к /var/sites/validate_rsync и отправил его пользователю user12: user12

Теперь синхронизация работает. Но я нашел статью, в которой говорится, что это небезопасно:

1- сама команда validate_rsync не должна принадлежать или записываться идентификатором пользователя, который выполняет команду rsync. В противном случае rsync можно использовать для перезаписи сценария проверки другим сценарием, который не проверяет и даже не выполняет произвольные команды.

2- аналогично, файл с авторизованными ключами не должен принадлежать или записываться пользователем rsync, в противном случае rsync может использоваться для перезаписи этого файла, с тем, который удаляет требование для запуска validate-rsync, или с тем, который запускает какую-либо другую команду вместо.

Источник

Что я могу сделать? Если validate_rsync принадлежит пользователю root, синхронизация не начинается, потому что user12 не может получить доступ rootфайлы. Если authorized-keys файл будет принадлежать другому пользователю, я не смогу войти в систему с именем пользователя user12.

Мои вопросы:

  1. Куда мне поместить файлы validate_rsync и авторизованных ключей, в каком каталоге? Какие разрешения и права собственности у них должны быть?

  2. Есть ли способ сказать validate_rsync файл, чтобы синхронизировать только 2 папки: /var/sites/photos/, /var/sites/photos2/

Эти опасения по поводу безопасности верны. Итак, чтобы ответить на ваш первый вопрос: чтобы он работал так, как вам нравится, вы должны поместить validate_rsync в каталог, где user12 имеет разрешение на выполнение, но не на запись. Тот самый validate_rsync файл должен иметь разрешения на чтение и выполнение для пользователя, но, конечно, не на запись. Проблема здесь в том, что /root по умолчанию доступен только для root пользователю, вам нужен путь, по которому каждый каталог имеет разрешение на выполнение для user12. Например, вы можете скопировать validate_rsync к /usr/local/bin и сделать его собственностью root. Так долго как user12 можно выполнять и читать, все в порядке.

Вам не нужно защищать свой authorized_keys файл. Лучше бы заставить user12 для запуска команды по конфигурации, вставив sshd_config последующий:

Match user user12
  ForceCommand /usr/local/bin/validate_rsync

Я думаю, что это решение лучше, чем возиться с authorized_keys.

Также в вашем validate_rsync Я бы процитировал $SSH_ORIGINAL_COMMAND (безопаснее), и я бы поменял твой case предложение для проверки правильности команды для регулярного выражения с помощью grep; проще, компактнее и мощнее:

echo "$SSH_ORIGINAL_COMMAND" >> /var/log/synchronize-log.log
if echo "$SSH_ORIGINAL_COMMAND" | grep -qE '[&;<>`|]'; then
  echo Rejected
elif [[ "${SSH_ORIGINAL_COMMAND:0:14}" == "rsync --server" ]]; then
  $SSH_ORIGINAL_COMMAND
else
  echo Rejected
fi

Чтобы ответить на ваш второй вопрос, при регистрации SSH_ORIGINAL_COMMAND вы можете запустить тест с каталогами, которые хотите рассмотреть, а затем проверить SSH_ORIGINAL_COMMAND, который вы получаете. Тогда вы могли бы сделать validate_rsync чтобы проверить только эту команду.

Чтобы защитить authorized_keys файл, я наткнулся на это решение: https://superuser.com/questions/852434/how-to-protect-authorized-keys-file

Довольно часто просто удаляют доступ для записи к этому файлу, если вы не планируете часто его менять.

chmod 400 ~/.ssh/authorized_keys

Теперь, конечно, этот доступ для записи может быть снова добавлен вредоносным скриптом, поэтому вам нужно сделать файл и его родительский каталог неизменными:

sudo chattr +i ~/.ssh/authorized_keys
sudo chattr +i ~/.ssh