gpg зашифровать файл без взаимодействия с клавиатурой [закрыто]

84

Я запускаю следующую команду в crontab, чтобы зашифровать файл, и мне не нужно взаимодействие с клавиатурой

echo "PASSPHRASE" | gpg --passphrase-fd 0 -r USER --encrypt FILENAME.TXT

но у меня есть такой ответ:

gpg: C042XXXX: There is no assurance this key belongs to the named user

pub  40XXX/C042XXXX 2012-01-11 Name LastName. (comment) <user@email.com>
 Primary key fingerprint: XXXX XXXX XXXX XXXX XXXX  XXXX XXXX XXXX XXXX XXXX
      Subkey fingerprint: XXXX XXXX XXXX XXXX XXXX  XXXX XXXX XXXX XXXX XXXX

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) 
Кото
источник
Поскольку --passphrase-fd читает только первую строку ... что произойдет, если вы запустите echo -e "PASSPHRASE" "\nyes" | gpg --passphrase-fd 0 -r USER --encrypt FILENAME.TXT?
Дэвид Коста
справочная страница кого-нибудь? --batchи --yes.
u0b34a0f6ae

Ответы:

76

Как намекнул Дэвид, проблема здесь в том, что gpg не доверяет открытому ключу, который вы используете для шифрования. Вы можете подписать ключ, как он объяснил.

Альтернативой - особенно если ключ может время от времени меняться - было бы привязать --trust-model alwaysк вашей команде gpg.

Вот соответствующий фрагмент на странице руководства:

--trust-model pgp|classic|direct|always|auto

     Set what trust model GnuPG should follow. The models are:

     pgp    This is the Web of Trust combined with trust signatures as used in
            PGP 5.x and later. This is the default trust model when creating a
            new trust database.

     classic
            This is the standard Web of Trust as used in PGP 2.x and earlier.

     direct Key validity is set directly by the user and  not  calculated  via
            the Web of Trust.

     always Skip  key  validation  and  assume that used keys are always fully
            trusted. You generally won't use this unless you  are  using  some
            external  validation  scheme.  This  option  also  suppresses  the
            "[uncertain]" tag printed with signature checks when there  is  no
            evidence that the user ID is bound to the key.

     auto   Select  the  trust  model depending on whatever the internal trust
            database says. This is  the  default  model  if  such  a  database
            already exists.
Rsaw
источник
Не понимаю, почему система думает, что это код. Я нажал цитату; не код. При редактировании он отображается только в кавычках (без цвета). Странно.
rsaw
4
это потому, что в тексте используются пробелы для выравнивания.
Tomáš Fejfar
это правильный ответ для меня! спасибо
eigenfield
46

Вот мое решение, основанное на gpg2 (но я уверен, что вы можете применить аналогичную технику к gpg)

$ gpg2 --edit-key {recipient email address}  
> trust
> 5 (select 5 if you ultimately trust the key) 
> save

Это скажет gpg2 полностью доверять ключу, чтобы вы могли зашифровать без запроса

Антоний
источник
1
Это немедленно обновляет trust-db, и никакого сохранения не требуется.
полосы
12
Это устанавливает доверие владельца, а не действительность ключа. Ultimate Trust только для ваших собственных ключей. т.е. все, что подписано полностью надежной идентификационной информацией, обрабатывается как подписанное вами. Так что НЕ ДОВЕРЯЙТЕ ULTIMATE, если это не ваш ключ. Проблема в правильности ключа. Чтобы решить / обойти это, вы должны подписать ключ. (рассмотрите только локальную подпись и проверку отпечатка пальца)
x539,
3
x539 правильно. после gpg2 --edit-key <key-id>того, как вы сделаете lsignи save. Я думаю, что доверие 5 - неправильное использование для этого (неправильно понятое), и (для меня) оно было даже неэффективным (бесполезным), потому что x539 сказал.
n611x007
Обратите внимание, что это также работает для обычных людей gpg, а не только для gpg2:)
Маркус
10

Хакерский подход:

echo -n PASSPHRASE > phrase
chmod 400 phrase #Make sure ONLY the user running the cron job can read the phrase
yes | gpg --passphrase-fd 3 --recipient USER --encrypt FILENAME.txt 3<phrase

Основная проблема заключается в том, что ключ для USER не подписан. Если вы ему доверяете, вы можете подписать его

gpg --edit-key USER sign

Вероятно, он задаст пару вопросов, в зависимости от вашей конфигурации. Сделайте это один раз, и тогда вы сможете войти в свой crontab. Я бы по-прежнему рекомендовал использовать предложенное мной решение, поместив кодовую фразу в отдельный файл и сделав ее доступной для чтения только одному пользователю, от имени которого запускается команда. Если вы это сделаете, вы можете убить yes |, и просто зашифровать строку.

Дэвид Саутер
источник
1
Я попробовал метод ключа подписи, оба gpg2 --edit-key USER sign, теперь он показывает, что он подписан, но все еще доверяет: неизвестно. И партия по-прежнему не запускается без подсказки
nycynik
2
Думаю lsignбыло бы получше. Разве это не так, если вы lsign т.е. локально подпишите ключ, этот знак останется на вашем компьютере. Но если вы просто подписываете, это считается общедоступным и, следовательно, будет отправлено на серверы ключей, когда вы сделаете --send-keys?
n611x007
2

Используйте эту команду, она вам поможет

echo "PASSPHRASE" | gpg --passphrase-fd 0 --always-trust -r USER --encrypt FILENAME.TX
Анил
источник
1

Я тоже столкнулся с этим. Я не мог получить ключ, чтобы сделать что-нибудь интересное. Вот что я сделал:

создать ключ gpg:

gpg --gen-key

получить длинный идентификатор ключа (результат в 5-м столбце):

gpg --list-keys --with-colon name@domain.tld

Добавьте строку доверенного ключа в ~ / gnupg / gpg.conf

trusted-key 16DIGITALPHANUMERICKEYID

Строка gpg в сценарии резервного копирования:

gpg -e -r name@domain.tld backup_file.tgz

Отладка cron: я также записываю выходные данные дублирования cron, отправляя stdout и stderr в файл журнала в командной строке cron. Полезно знать

Йорфус
источник
1
Нет, не делай этого. Добавление trusted-keyстроки в gpg.confприведет gpgк тому, что вы всегда будете доверять этому ключу так же полно, как одному из собственных ключей пользователя , что плохо . Передача --trusted-keyв качестве аргумента и только в этом конкретном случае приемлема (как и передача --trust-model=alwaysтаким же образом ).
Blacklight Shining
Это мой ключ. Разве это не то, что я хочу отметить как доверенный?
jorfus
1
Если это действительно ваш ключ, то да, пометьте его как полностью надежный (хотя я лично предпочитаю делать это с помощью --edit-key, а не добавляя trusted-keyстроку). Спрашивающий не сказал, что жалуется на собственный ключ gpg.
Blacklight Shining
1

Я предполагаю, что, как и я, многие люди приходят сюда для того, чтобы ответить на вопрос «без взаимодействия с клавиатурой». С gpg2 и gpg-agent стало довольно сложно подписывать / шифровать / расшифровывать данные без какого-либо взаимодействия с клавиатурой. Вот как можно создать подпись, если кодовая фраза закрытого ключа в виде открытого текста сохраняется в текстовом файле:

cat something_so_sign.xzy | gpg \
    --passphrase-file "plaintext_passphrase.txt" \
    --batch \
    --pinentry-mode loopback \
    -bsa

Измените -b -s -a в зависимости от ваших потребностей. Остальные переключатели обязательны. Вы также можете просто использовать --passphrase 'SECRET'. Как уже указывалось, будьте осторожны с этим. Текстовые файлы с открытым текстом, конечно, не намного лучше.

LimeRed
источник
0

Или подпишите ключ (разумеется, после того, как вы вернете отпечаток пальца):

gpg --sign-key <recipient email address>

После этого вы полностью доверяете ключу.

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
переулки
источник
5
Доверие к собственнику не имеет ничего общего с этой проблемой. Устанавливайте доверие владельца только в том случае, если вы доверяете ему в отношении подписи / проверки других ключей и их владельцев
x539
Йенес, почему бы не отредактировать свой ответ, чтобы обновить информацию о доверии ключей? В настоящее время может вводить в заблуждение ... --lsign-keyМожет быть, лучше, не так ли? см. мой другой комментарий о lsign
n611x007
0

введите описание изображения здесь

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

Не факт, что ключ принадлежит человеку, указанному в идентификаторе пользователя. Если вы действительно знаете, что делаете, вы можете ответить утвердительно на следующий вопрос.

Все равно использовать этот ключ? (да / нет)

Сумер Радж
источник
0

Другой подход: чтобы запретить доступ к конфиденциальным данным (вместо того, чтобы шифровать их с помощью сторонних ключей), я загружаю ТОЛЬКО * свой ** ПУБЛИЧНЫЙ ключ на сервер, на котором я хочу защитить данные, и использую этот ключ для шифрования. Это устраняет необходимость в интерактивном запросе для ввода пароля, что упрощает автоматизацию, и, что самое важное , ЧАСТНЫЙ ключ находится отдельно от общедоступного сервера.

gpg --batch --yes --trust-model always -r $YOURPUBKEYEMAILADDRESS -e ./file.txt

Однако, если НЕ выполняется шифрование с использованием собственного открытого ключа, использование переключателя --trust-model alwaysбудет немного рискованным. Во всяком случае, другой способ решения проблемы отказа в доступе к данным. HTH - Терренс Хоулахан

F1Linux
источник