Шифрование файла только с SSH - priv-ключ?
Вы могли запустить путем помещения robsio в /etc/modules или везде, где Ваш дистрибутив ищет модули для загрузки на времени начальной загрузки (обычно после того, как он сделает автоматическое обнаружение). Это могло бы быть /etc/modules.d/_____ в Вашей системе.
После этого просьба о proc записи могла бы быть чем-то, что Вы делаете в коде модуля, но это вне моего поля экспертных знаний, таким образом, я оставлю его для гуру.
Я думаю, что Ваше требование допустимо, но с другой стороны это также трудно, потому что Вы смешиваете симметричное и асимметричное шифрование. Исправьте меня, если я неправ.
Обоснование:
- Пароль для Вашего закрытого ключа состоит в том, чтобы защитить Ваш закрытый ключ и ничто иное.
- Это приводит к следующей ситуации: Вы хотите использовать свой закрытый ключ для шифрования чего-то, что только можно дешифровать. Ваш закрытый ключ не предназначается для этого, Ваш открытый ключ там, чтобы сделать это. Независимо от того, что Вы шифруете со своим закрытым ключом, может быть дешифрован Вашим с открытым ключом (подписание), это, конечно, не, что Вы хотите. (Независимо от того, что шифруется Вашим открытым ключом, может только быть дешифрован Вашим закрытым ключом.)
- Таким образом, необходимо использовать открытый ключ для шифрования данных, но для этого, Вам не нужен Ваш пароль с закрытым ключом для этого. Только если Вы хотите дешифровать его, Вам были бы нужны Ваш закрытый ключ и пароль.
Заключение: В основном Вы хотите снова использовать свой пароль для симметричного шифрования. Единственная программа, которую Вы хотели бы дать своему паролю, является ssh-агентом, и эта программа не делает шифрования/дешифрования только с паролем. Пароль только там для разблокирования закрытого ключа и затем забытый.
Рекомендация: использовать openssl enc или gpg -e --symmetric с защищенными от пароля файлами ключей для шифрования. Если необходимо поделиться информацией, можно использовать открытый ключ infrastucture обеих программ для создания PKI/сети Доверия.
С openssl, чем-то вроде этого:
$ openssl enc -aes-256-ctr -in my.pdf -out mydata.enc
и дешифрование что-то как
$ openssl enc -aes-256-ctr -d -in mydata.enc -out mydecrypted.pdf
Обновление: важно отметить, что вышеупомянутое openssl команды НЕ препятствует тому, чтобы данные вмешались. Простое разрядное зеркальное отражение в enc файле приведет к поврежденным дешифрованным данным также. Вышеупомянутые команды не могут, обнаружил это, необходимо проверить это, например, с хорошей контрольной суммой как SHA-256. Существуют криптографические способы сделать это интегрированным способом, это называют HMAC (Основанный на хеше Код аутентификации сообщений).
Взгляд luks/dm-crypt. Можно использовать ssh-закрытый-ключ в качестве ключа шифрования при помощи подходящего варианта.
Обновление: шифрование В качестве примера с помощью LUKS с блочным устройством LV (тест LV в системе VG):
KEY=/home/youraccount/.ssh/id_dsa
DEVICE=/dev/system/test
cryptsetup luksFormat $DEVICE $KEY
cryptsetup luksOpen $DEVICE test_crypt --key-file $KEY
Это должно gnerate блочное устройство/dev/mapper/test_crypt, который можно использовать, чтобы хранить данные на (после форматирования его с файловой системой по Вашему выбору).
Избавиться от него, umount он, и использование cryptsetup luksClose test_crypt.
-
1Вы могли дать MVO, чтобы сделать так, это легко к повторному использованию?
"$ sudo apt-get install cryptmount crypt-setup; cat '...' > bin/myEncrypt.sh; chmod +x bin/myEncrypt.sh; ./bin/myEncrypt.sh; ...; ..."Если я могу понять право, этот метод является шифрованием уровня файловой системы. Это шифрует фс, которая Вам требуется umount/mount, или я неправильно читаю это? – 01.03.2012, 02:18 -
2я не думаю, что это делает то, что Вы думаете, что он делает.
--key-fileопция к cryptsetup использует фактическое содержание файла как один большой пароль. Это не читает openssl ключ из файла и просто использует это. Можно использовать файл случайных байтов для--key-fileесли Вы хотите. – Patrick 02.03.2012, 09:26 -
3
-
4@Nils, но что происходит, когда он изменяет пароль на своем закрытом ключе, он будет теперь не мочь дешифровать свои файлы как данные в измененном файле ключей.
--key-fileдействительно плохо выбранное название опции, это должно быть--password-file– Patrick 03.03.2012, 01:31 -
5@Patrick Это верно - изменение пароля, изменит файл и таким образом ключ (с точки зрения удач). Но даже с точки зрения ssh я не назвал бы это файлом паролей. Я знаю, что мой ответ не попадает в десятку - но я думаю, что он обеспечит некоторые идеи. – Nils 03.03.2012, 23:32
Я предпочел бы использовать openssl утилита, поскольку это, кажется, довольно повсеместно.
Преобразуйте открытый ключ RSA и закрытый ключ к формату PEM:
$ openssl rsa -in ~/.ssh/id_rsa -outform pem > id_rsa.pem
$ openssl rsa -in ~/.ssh/id_rsa -pubout -outform pem > id_rsa.pub.pem
Шифрование файла с открытым ключом:
$ openssl rsautl -encrypt -pubin -inkey id_rsa.pub.pem -in file.txt -out file.enc
Дешифрование файла с закрытым ключом:
$ openssl rsautl -decrypt -inkey id_rsa.pem -in file.enc -out file.txt
Но, как Gilles прокомментировал выше этого, только подходит для шифрования файлов, меньших, чем Ваш открытый ключ, таким образом, Вы могли сделать что-то вроде этого:
Генерируйте пароль, зашифруйте файл с ним симметрично и зашифруйте пароль со своей общественностью, ключ, сохраняющий его в файл:
$ openssl rand 64 |
tee >(openssl enc -aes-256-cbc -pass stdin -in file.txt -out file.enc) |
openssl rsautl -encrypt -pubin -inkey id_rsa.pub.pem -out file.enc.key
Дешифруйте пароль со своим закрытым ключом и используйте его для дешифрования файла:
$ openssl rsautl -decrypt -inkey id_rsa.pem -in file.enc.key |
openssl enc -aes-256-cbc -pass stdin -d -in file.enc -out file.txt
Вы закончите с двумя файлами, Вашим зашифрованным файлом и Вашим зашифрованным паролем, но поместите в сценарий, он работал бы приятно.
Вы могли даже добавить a tar cvf file file.enc file.enc.key убраться.
Оптимально, Вы максимизировали бы размер своего пароля, также изменяющегося rand 64 к размеру Вашего открытого ключа.
-
1
-
2только что нашел это, хорошее сообщение. Я нашел, что максимальный симметричный ключ размера, который можно генерировать от ssh-ключа, на 12 байтов короче, чем сам ssh-ключ иначе, rsautl перестал бы работать с "данными, слишком большими для размера ключа". Таким образом, это работало в сценарии:
KEYLEN_BYTES=$(ssh-keygen -l -f $PRIV_KEY | awk '{printf("%d", ($1 - 96) / 8)}')к autogen длина ключа. Данный ssh-keygen имеет минимум keylength 768 битов, это все еще приводит к минимальному симметричному ключу 672 битов или 84 байтов. – markf 18.12.2012, 18:15
"gpg -e something"но для различных случаев? – 04.03.2012, 00:25$ gpg -e --symmetric? – 05.03.2012, 11:14openssl enc -aes-256-cbc -in my.pdf -out mydata.enc, дешифруйте с:openssl enc -aes-256-cbc -d -in mydata.enc -out mydecrypted.pdfобе команды просят пароль. Посмотритеman enc(на rh/fedora/centos) для всех опций как файлы ключей, base64 кодирующий и т.д. – vasquez 05.03.2012, 14:55