Я прочитал несколько статей о том, как автоматически создавать резервные копии файлов с помощью Rsync и аутентификации с открытым ключом. Все они очень похожи. Я только что закончил настраивать все, и все работает нормально, но ... Я только что нашел статью, в которой говорится, что это небезопасно. Я сделал следующее:
/var/sites/.ssh
(файл authorized_keys
). Каталог принадлежит "user12"
from="BACKUP.SERVERS.IP.ADDRESS",command="/root/validate_rsync"
Я создал файл / 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
.
Мои вопросы:
Куда мне поместить файлы validate_rsync и авторизованных ключей, в каком каталоге? Какие разрешения и права собственности у них должны быть?
Есть ли способ сказать 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