Алгоритм или бестпрактис для синхронизации .dotfiles?

Question

[Tech]

Исходные данные. Работаю поочередно за тремя компами (дома комп и ноут + на работе комп).
Синхронизирую конфиг систем и дотфайлы домашнего каталога через ансибл и его модуль rsync. Таким образом, везде всё одинаковое.
Но есть большой недостаток - в алиасах баша открытым текстом пароли виндовых хостов и их пользователей. Этих алиасов очень много.
В принципе все алиасы freerdp вынесены в отдельный файл .freerdp_aliases, который инклудится из .bashrc.
По понятным причинам компрометация этого файла - последнее чего бы хотелось.

Предполагаю, что можно сделать его зашифрованным через openssl и именно его синхронизировать или даже версионировать через git (или оставить текущую схему с ансибл). При входе в систему расшифровывать его, кладя в RAM и подключать через "source .bashrc". Работать. После окончания рабочего дня расшифрованный файл надо удалить (ну или изначально при начале работы класть его в RAM).
Но в этот файл регулярно вносятся изменения, бывает раз в день, а бывает лишь один раз в месяц.

Значит после внесения изменений в него, его надо зашифровать. и затереть этим новым шифрованным файлом старый зашифрованный файл. И это желательно делать автоматически, как только внесены изменения в расшифрованный файл, чтобы исключить фактор "забыл руками это сделать", отключение электричества etc. Тут еще паралельный вопрос: А если я не запушил в git эти изменения, и потом еще отредактировал файл на одном или двух своих других хостах, там зашифрованный файл будет оличаться, то гит разрулит зашифрованные файлы как-то?

Какой алгоритм и инструменты посоветуете?

Comments

[shurshur]

Лучше вынести секреты в отдельный файл, а его шифровать или gnupg, или ansible-vault. Приватный ключ для gnupg в любом случае не надо класть в git, а доставлять отдельным механизмом.

Для управления шифрованными файлами в целом можно использовать pass https://wiki.archlinux.org/title/Pass, который комбинирует gnupg и git для хранения шифрованных файлов с неплохим cli-интерфейсом.

Ну а вообще я бы посмотрел на готовые dotfiles-менеджеры типа yadm.

[Tech]

shurshur, yadm видел да, присматриваюсь. Но хотелось бы сначала разобраться на базовом уровне, а потом уже обёртки использовать.

Кстати, я не gnupg хотел, а openssl-ом шифровать так:

openssl enc -aes-256-cbc -pbkdf2 -iter 1234569 -salt -in .xfree_aliases -out .xfree_aliases_encrypted

Насколько безопасно такой файл (.xfree_aliases_encrypted )закидывать в git?

[shurshur]

Tech, если тут ключом выступает 1234569, то опасно. Достаточно узнать это число и всё, Не говоря уже о возможности подбора брутфорсом.

Ключи для RSA, например, делают как минимум 1024 бита, а тут всего 20 бит.

[shurshur]

Tech, добавлю, что для исключения раскрытия данных при наличии физического доступа надо все ключи закрывать пассфразами и использовать агенты (ssh-agent, gpg-agent). Если всё правильно сделать, ключи будут использоваться только на той машине, с которой залогинен, а дальше прокидываться по ssh. И секретный ключ можно держать на железном носителе типа yubikey (самый известный, есть и другие варианты). Да, это придётся поразбираться и повозиться. Да, yubikey стоит некоторых денег и его может быть сложнее купить в условиях санкций.

[Tech]

shurshur, это не ключ. Это итерации соли. Пароль запоашивается отдельно.

[shurshur]

Tech, ну, я не пробовал такой метод, так что поверю на слово :)

Answer 1

[Василий Банников]

Бест практиса не существует.
Есть очень дохрена разных инструментов, вплоть до специального модуля для ансибла.

Ну и я бы ещё на всякий случай, через гит всё это протаскивал, чтобы каждой машине не нужно было знать о других машинах.

https://project-awesome.org/webpro/awesome-dotfiles

Answer 2

[Saboteur]

Предполагаю, что можно сделать его зашифрованным через openssl и именно его синхронизировать или даже версионировать через git (или оставить текущую схему с ансибл). При входе в систему расшифровывать его, кладя в RAM и подключать через "source .bashrc". Работать. После окончания рабочего дня расшифрованный файл надо удалить (ну или изначально при начале работы класть его в RAM).
Но в этот файл регулярно вносятся изменения, бывает раз в день, а бывает лишь один раз в месяц.

Не самый плохой вариант шифровать через openssl.
Только зачем расшифровывать файл? Расшифровывайте прямо в память во время использования

то есть в .bashrc можно например так

dbuser=database_user
dbpass="$(openssl enc -d -base64 -aes-128-ctr -nopad -k secret_key.txt<<<"l1k2j3kl14jjkl321h4lk124123;ljk2`13jlkj")"

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

Answer 3

[pfg21]

если уже используешь rsync, то посоветую подняться чутка и выше и перейти на демона syncthing.
связь между клиентами качественно шифрована. никаких левых облаков и серверов - все данные только на своих компутерах. передача изменений в онлайн
есть возможность на некоторых клиентах хранить шифрованную копию раздачи без возможности доступа к файлам.
есть несколько вариантов по сохранению измененных файлов (простая корзина и сложнее)

Comments

[Tech]

Суть ещё в том, чтобы исключить компрометацию при наличии физического доступа к компу. А шифровать разделы, не хочу, так как там вовлекаются аспекты быстродействия диска и trim (я просто не в курсе, как с этим сейчас).

[pfg21]

Tech, при наличии физического досутпа к компу я сниму и файл с зашифрованными паролями и скрипт расшифровки этих паролей и все пароли получу :)
простые костыли тут не прокатывают.

[Tech]

pfg21, даже если файл зашифрован паролем?

[pfg21]

Tech, о чем и говорю.
некий файл зашифрован паролем.
рядом лежит скрипт, который расшифровывает это файл для использования, в скрипте лежит открытым текстом пароль к зашифрованному файлу.
тупой костыль, "типа" шифрующий файл от преступника :)

[Tech]

pfg21, нет. Пароль для расшифровки файла я планирую вводить каждый раз, когда стартует система. Хранить этот пароль открытым текстом я и не собирался. Иначе смысл всего этого вопроса в посте теряется.