bash gpg 加密文件而无需键盘交互

gpg encrypt file without keyboard interaction

提问by coto

I am running next command within a crontab to encrypt a file and I don't want a keyboard interaction

我正在 crontab 中运行下一个命令来加密文件，但我不想要键盘交互

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

but I have this answer:

但我有这个答案：

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

pub  40XXX/C042XXXX 2012-01-11 Name LastName. (comment) <[email protected]>
 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) 

采纳答案by rsaw

As David intimated, the problem here is that gpg doesn't trust the public key you're using to encrypt. You could sign the key as he explained.

正如大卫暗示的那样，这里的问题是 gpg 不信任您用来加密的公钥。你可以按照他的解释在钥匙上签名。

An alternative--especially if the key might be changing occasionally--would be to tack on --trust-model alwaysto your gpg command.

另一种选择——特别是如果密钥可能偶尔会改变——将附加--trust-model always到您的 gpg 命令。

Here's the relevant bit from the man page:

这是手册页中的相关部分：

--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.

--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.

回答by Antony

Here is my solution, based on gpg2 (but I bet you can apply similar technique to gpg)

这是我的解决方案，基于 gpg2（但我敢打赌您可以将类似的技术应用于 gpg）

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

This will tell gpg2 to trust the key fully, so that you can encrypt without prompt

这将告诉 gpg2 完全信任密钥，以便您可以在没有提示的情况下进行加密

回答by David Souther

The hack approach:

黑客方法：

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

The underlying problem is that the key you have for USER isn't signed. If you trust it, you can sign it with

潜在的问题是您拥有的 USER 密钥未签名。如果你信任它，你可以用它签名

gpg --edit-key USER sign

It will probably ask a couple questions, depending on your configuration. Do this once, then you should be good to go in your crontab. I'd still recommend using the solution I proposed, putting the passphrase in a separate file and making it only readable by the one user that command runs as. If you do that, you can kill the yes |, and just have the encrypt line.

它可能会问几个问题，具体取决于您的配置。这样做一次，然后你应该很高兴进入你的 crontab。我仍然建议使用我提出的解决方案，将密码放在一个单独的文件中，并使其只能由运行命令的用户读取。如果你这样做，你可以杀死yes |, 并且只拥有 encrypt 行。

回答by Anil

Use this command, it will help you

使用这个命令，它会帮助你

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

回答by LimeRed

I assume that like me, a lot of people come here for the 'without keyboard interaction' part of the question. With gpg2 and gpg-agent it got quite complicated to sign/encrypt/decrypt stuff without any keyboard interaction. Here is how you would create a signature when your plaintext private key passphrase is saved in a text file:

我想和我一样，很多人来这里是为了问题的“无键盘交互”部分。使用 gpg2 和 gpg-agent，在没有任何键盘交互的情况下对内容进行签名/加密/解密变得非常复杂。当您的纯文本私钥密码短语保存在文本文件中时，您将如何创建签名：

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

Change -b -s -a depending on your needs. The other switches are mandatory. You may also just use --passphrase 'SECRET'. As already pointed out, be careful with that. Plaintext textfiles are not that much better of course.

根据您的需要更改 -b -s -a。其他开关是强制性的。您也可以只使用--passphrase 'SECRET'. 正如已经指出的那样，要小心。当然，纯文本文本文件并没有那么好。

回答by jorfus

I was running into this too. I couldn't get sign-key to do anything interesting. Here's what I did:

我也遇到了这个。我无法获得签名密钥来做任何有趣的事情。这是我所做的：

create a gpg key:

创建一个 gpg 密钥：

gpg --gen-key

get long key ID (result is in 5th column):

获取长密钥 ID（结果在第 5 列中）：

gpg --list-keys --with-colon [email protected]

Add trusted key line to ~/gnupg/gpg.conf

将可信密钥行添加到 ~/gnupg/gpg.conf

trusted-key 16DIGITALPHANUMERICKEYID

gpg line in backup script:

备份脚本中的 gpg 行：

gpg -e -r [email protected] backup_file.tgz

Debugging cron: I'm also capturing cron dubugging output by sending stdout and stderr to a log file in the cron command line. It's helpful to know

调试 cron：我还通过将 stdout 和 stderr 发送到 cron 命令行中的日志文件来捕获 cron 调试输出。知道是有帮助的

回答by sumer raj

When you create a certificate first time with your email-id select fully trusted certificate then whenever you encrypt any file will not ask question like.... for more information open image in above link.

当您第一次使用您的电子邮件 ID 创建证书时，请选择完全信任的证书，然后无论何时加密任何文件都不会问诸如...之类的问题，有关更多信息，请在上面的链接中打开图片。

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

Use this key anyway? (y/N)

不确定密钥是否属于用户 ID 中指定的人。如果你真的知道你在做什么，你可以用是的回答下一个问题。

还是要用这个键？(是/否)

回答by F1Linux

A different approach:To deny accessto sensitive data (rather than encrypt it using third-party's keys), I upload ONLY* my **PUBLICkey to the server I want to protect data on and use that key to encrypt with. This negates the need for an interactive prompt to supply a password facilitating automation and best of all, the PRIVATEkey is apart from the public server.

一种不同的方法：为了拒绝访问敏感数据（而不是使用第三方的密钥对其进行加密），我只将我的 **PUBLIC密钥上传到我想要保护数据的服务器并使用该密钥进行加密。这否定了一个交互式提示提供密码促进自动化的需要，最重要的是，该PRIVATE关键是除了公共服务器。

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

However, if NOTencrypting with your own public key, the use of the switch --trust-model alwaysis a bit ropey. Anyway, a different way of solving the problem of denying access to data. HTH- Terrence Houlahan

但是，如果不使用您自己的公钥加密，则使用开关--trust-model always有点麻烦。无论如何，这是一种解决拒绝访问数据问题的不同方法。HTH-特伦斯·霍拉汉

回答by lanes

Or sign the key (after you veryfied the fingerprint, of course):

或者在密钥上签名（当然，在您输入指纹之后）：

gpg --sign-key <recipient email address>

After that you fully trust the key.

之后，您完全信任密钥。

  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