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

Я запускаю следующую команду в 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) 

Как намекнул Дэвид, проблема здесь в том, что 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.

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

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

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

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

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 |, и просто зашифровать строку.

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

echo "PASSPHRASE" | gpg --passphrase-fd 0 --always-trust -r USER --encrypt FILENAME.TX

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

создать ключ 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. Полезно знать

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

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

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

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

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

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

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

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

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

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

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