LINUX.ORG.RU

encrypted fs over sshfs

 , , ,


0

1

Всем доброго дня.

Возникла следующая потребность: Есть некое удалённое хранилище ( подключаем по sshfs, не локальная сеть ). Хочется организовать прозрачное шифрование в этом хранилище - т.е. когда мы туда что-то копируем - оно шифруется на лету до записи, когда читаем - наоборот дешифруется. Хотелось бы именно поддержку обычных ф-ций чтения записи ( т.е. приложению не надо знать что это зашифрованный сетевой диск, ему даже пароль бы знать не надо ). Как-то смотрю в сторону encfs, но может кто посоветует что другое ? весь зоопарк в Centos 6..7

Заранее спасибо всем откликнувшимся.


EncFS заброшена, так что лучше CryFS (C++, бета, есть тезис, умеет скрывать размер файла) или GocryptFS (Go, вроде стабильная, хороший код). Если не нужно скрытие размера файла, то я бы выбрал вторую.

anonymous
()
Ответ на: комментарий от anonymous

Хотя аудит показал, что gocryptfs не очень местами.

anonymous
()

Немного тяжелой наркомании

Покупаем OpenPGP карту и ридер или совместимый токен, генерим пары ключей через gpg для аутентификации и шифрования, запихиваем закрытые ключи на карту. Настраиваем аутентификацию ssh по ключю gpg ( всё работает легко и просто из коробки ). На сервере разрешаем проброс gpg с клиента, создаём LUKS раздел с аутентификацией по файлу ключу. Ключик шифруем своим открытым ключем, оригинал удаляем.

При подключении пользователя открываем шифрованный раздел:

gpg2 -qd key.gpg | sudo cryptsetup --key-file - luksOpen /dev/secret secret && mount /dev/mapper/secret /...

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

При разлогировании

umount /dev/mapper/secret && cryptsetup luksClose secret

Profit.

sparks ★★★
()
17 января 2019 г.
Ответ на: Некропостну от TheAnonymous

Да, там так и написанно

При подключении пользователя открываем шифрованный раздел:

gpg можно пробрасывать каскадом по ssh

sparks ★★★
()
Ответ на: комментарий от sparks

Так на сервере можно тупо подменить cryptsetup и получить ключ в открытом виде.
Да и вообще смысла хранить ключ симметричного шифра на смарткарте немного

TheAnonymous ★★★★★
()
Ответ на: комментарий от TheAnonymous

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

sparks ★★★
()
Ответ на: комментарий от sparks

Почему это? Должно быть предусмотрено, если сервер не доверенный, который ты не контролируешь, скажем, это какой-то VPS.
Про подмену cryptsetup это один из вариантов, а можно например просто слить дамп оперативки с виртуалки и вытащить ключ оттуда

TheAnonymous ★★★★★
()
Ответ на: комментарий от TheAnonymous

Или просто подождать пока пользователь «откроет»/«расшифрует» раздел/фс и просто скопировать содержимое директории.

sparks ★★★
()
Ответ на: комментарий от sparks

Вот именно, потому ключ не должен отправляться на сервер, а (рас)шифрование должно производиться на локальной машине

TheAnonymous ★★★★★
()
Последнее исправление: TheAnonymous (всего исправлений: 1)

можно ещё rclone попробовать с crypt бэкендом

anonymous
()
Ответ на: комментарий от sparks

Всё о том же, если серверу не доверяешь, то операции шифрования надо производить локально, а на сервер отправлять только зашифрованные данные.

Как пример - просто encfs/cryfs/gocryptfs поверх sshfs (или там монтировать локальную папку в режиме reverse, как умеет encfs или gocryptfs, и потом синкать зашифрованное «отображение» через rsync)

TheAnonymous ★★★★★
()
Ответ на: комментарий от TheAnonymous

Luks + iSCSI ?

sshfs это sftp, т.е. если ssh демон на сервере в состоянии это прочитать и отправить, хацкер тоже сможет это прочитать. а если подменить sftp submodule на свой, то вообще можно что хочешь творить с передаваемыми данными.

sparks ★★★
()
Ответ на: комментарий от sparks

Luks + iSCSI

Тоже как вариант.

ssh демон на сервере в состоянии это прочитать и отправить, хацкер тоже сможет это прочитать. а если подменить sftp submodule на свой, то вообще можно что хочешь творить с передаваемыми данными

Так если поверх sshfs ещё encfs/cryfs/gocryptfs, то пусть читает, это уже зашифрованные данные

TheAnonymous ★★★★★
()
Последнее исправление: TheAnonymous (всего исправлений: 1)
Ответ на: комментарий от TheAnonymous

Так если поверх sshfs ещё encfs/cryfs/gocryptfs, то пусть читает, это уже зашифрованные данные

ооооооооооочеееееень медленно будет работать

sparks ★★★
()
Ответ на: комментарий от sparks

Да не обязательно, encfs вообще по скорости будет практически так же, как просто sshfs (всё равно упрётся в ssh и скорость интернетов до него)

TheAnonymous ★★★★★
()
Ответ на: комментарий от anonymous

А, перепутал. Я говорю про ecryptfs, которая ядерная.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.