我想在没有任何用户交互的情况下使用GnuPG的decrypt
命令。脚本的--passphrase-fd
参数似乎正是我所需要的。但我不知道它是如何工作的 - 没找到例子。
在Windows和UNIX环境下,有人能给我一个这样的命令的例子吗?
(仅供参考,我正在使用GnuPG 2)。
非常感谢:)
答案 0 :(得分:35)
要在GnuPG v2中使用gpg选项--passphrase-fd
,您必须指定--batch
参数。我将首先解释--passphrase-fd
如何工作,然后进入示例。
--passphrase-fd
告诉GnuPG file descriptor( - fd)期望密码来自哪个。标准文件描述符是STDIN(0),STDOUT(1)和STDERR(2)。对于这个问题的上下文,通常只关注STDIN(0)。
您没有指定密码短语的来源,因此我将以各种方式演示STDIN(标准输入)的用法。
--passphrase-fd 0
告诉GnuPG从输入中检索密码短语到当前shell;例如,如果您希望GnuPG在下一行控制台输入中获取密码短语数据,则命令和输出将如此:
gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
<next line of input is passphrase followed by hitting enter>
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <test@4321.com>"
this is a test... this is only a test...
在上面的例子中,密码是通过文件描述符0(STDIN)提供的 - 我们通过在shell当前标准输入上输入它来提供。
在下一个例子中,我们将告诉GnuPG从输入中检索密码短语到当前shell,它实际上是另一个命令的输出(echo,在这种情况下,它只是“回声”你告诉它的内容):< / p>
echo "mypassphrase" | gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <test@4321.com>"
this is a test... this is only a test...
将包含密码的文件内容转储到STDIN -
的另一个示例cat /path/to/file_with_passphrase | gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <test@4321.com>"
this is a test... this is only a test...
总之,--passphrase-fd
只是告诉GnuPG您希望通过标准文件描述符为其提供必要的密码短语; GnuPG v2和GnuPG之间的区别仅仅是--batch
参数。
以上示例在Windows和* nix环境中应该相同,唯一的区别是在Windows中 - 取决于您的配置和版本 - 您必须将cat
替换为type
in为了将文件的内容转储到STDIN。
答案 1 :(得分:19)
根据https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase gnupg 2.1.0及更高版本,您需要执行其他步骤来支持--passphrase-fd
首先,编辑gpg-agent配置以允许环回pinentry模式: 〜/ .gnupg / GPG-agent.conf
allow-loopback-pinentry
如果gpg-agent进程正在运行,请重新启动以使更改生效。
其次,要么需要更新应用程序以包含命令行参数以使用环回模式,如下所示:
$ gpg --pinentry-mode loopback ...
答案 2 :(得分:4)
使用GPG4win / gpg 2.2.3:使用passphrase-fd 0
并绕过提示,我可以确认以下内容有效:
--pinentry-mode loopback
答案 3 :(得分:2)
由于我最近不得不自己解决这个问题,所以我觉得值得一试。
如果您正在解密文件,kylehuff的答案非常好,但是,如果您需要输入/输出重定向,例如管道,这里是使用非的示例传递密码短语的0
文件描述符。
#!/usr/bin/env bash
# Set some variables for easy modding
Var_fd='9'
Var_pass_location="/path/to/passphrase.file"
Var_gpg_decrypt_opts="--passphrase-fd ${Var_fd} --decrypt"
Var_output_location="out.txt"
Arr_string=( "$@" )
# Open file descriptor and shove the passphrase file into it
exec ${Var_fd}<${Var_pass_location}
# Pipe input array though gpg and append to output file
cat <<<"${Arr_string[*]}" | $(which gpg) ${Var_gpg_decrypt_opts} >> ${Var_output_location}
# Do not forget to close the file descriptor
exec ${Var_fd}>&-
在特殊用例之外,请注意,保存私钥密码通常被视为一个坏主意或不良安全措施。 - 请不要忘记在完成后忘记关闭描述符,以便您的密码不再可以通过该方法访问.-我经常看到在这些用例中建议使用特定的非密码短语保护钥匙,但这完全是你的选择。如果您喜欢上面的代码,那么您可能还需要检查我为key generation调试的无人参与或无人值守的脚本,因为它涵盖了更常用的gpg文件描述符选项。
所以我一直在调试批量解密操作,并且有证据表明文件描述符似乎自动关闭,或者它可能被GnuPG自动关闭。检查原始日志底部的构建152,在diff
检查之前,您会发现第一个加密数据块吃密码短语在没有有效密码的情况下留下接下来的两个数据块。此操作中的相关脚本是;首先,script_decrypt.sh构建脚本将测试密钥的密码设置为文件描述符9
,如上面的示例所示,然后调用Helper script以便它可以使用该文件描述符...它是一个时髦的用例,但故事的寓意似乎是你计划用GnuPG文件描述符实现的批量解密操作可能需要遵循上面列出的整体步骤函数正确地重新打开文件描述符。我将在接下来的几次推送中重写帮助脚本,因此请检查大于152
的{{3}}构建日志,以查找我是否解决了文件描述符关闭的问题。 。
...所以只需要两次尝试就能完成工作,看看build Travis-CI与加密文件和原始输入日志匹配的区别。假设文件描述符在GnuPG或子shell首次使用后被转储,因此需要在每个解密命令之前分配密码,以便进行批量解密。
希望这对所有人都有价值。