web-dev-qa-db-ja.com

gpg2のgpg-agentの目的

しばらくの間、暗号化にgpgを使用しています。代わりにgpg2を使用するように提案されました。 gpg2を使いに行ったとき、ほとんど何もできませんでした。秘密鍵へのアクセスが必要であると文句を言うでしょうが、gpg-agentを実行しないと秘密鍵を使用するようにできなかったようです。

I 意図的に無効gpg-agentchmod -x /usr/bin/gpg-agentを使用)であることが判明しました。これにより、gpg2の機能が非常に制限され、stderrに文句が表示されました。

gpg-agentを無効にした理由は、一連のイベントを追跡したためです。

まず、リモートマシンにSSHで接続すると、「エージェント」がポップアップを開いて、SSHキーのロックを解除するように求めます。私はこれが好きではありませんでした:

  • 画面上のポップアップがワークフローを中断します
  • 画面上のポップアップに気付かない可能性が高いため、暗号化キーのロックを解除するためにクエリを実行する代わりに、接続が停止しているように見えます
  • パスワードをキャッシュしたくないときに、エージェントがパスワードをキャッシュしているように見えました(Sudoのパスワードキャッシュの煩わしい使用と同様に、構成で無効にできます)。暗号化キーのパスフレーズを常に入力したいと思いますそれらを使用しているプログラムで使用されるたびに
  • ポップアップは別のプロセスによって所有されているように見えましたが、キーを使用する特定のプロセスでパスフレーズをクエリする必要があります(実際のクエリを実行するライブラリであっても)。私はほとんどのアクティビティをコマンドラインツールを使用して費やしているので、つまりGUIアプリケーションは理想的ではありません。私が行うすべての操作がX11にアクセスできるわけではないからです。
  • バックグラウンドで別のプロセスを自動的に開始すると、「1つのコマンド、1つのプロセス」の概念が削除されます。特に、そのバックグラウンドプロセスが元のコマンドの終了後に残る場合は、

それはGNOMEの主要なエージェントであることが判明し、GNOMEをアンインストールせずにエージェントをアンインストールできませんでした。だから私は単にchmod -x /usr/bin/gnome-keyring*でそれを無効にしました。その後、SSHが別のエージェントにフォールバックすることがわかったので、同じ方法を使用してそれも無効にしましたchmod -x /usr/bin/ssh-agent*

gpgを使い始めたとき、私が尋ねているのと同じエージェントがあったことがわかりました。同じ理由ですぐに無効にしました。ソフトウェアに常に秘密鍵を使用するためにパスフレーズを要求してほしい。なんらかの理由でパスフレーズをキャッシュしたくありません。

したがって、gpg2requiregpg-agentに表示されるので、次のように質問します。

  • パスフレーズキャッシュの使用について過度に妄想していますか?私はそれについての議論を見たり、指摘されたりしたいと思います。
  • キャッシュされたパスフレーズの使用を誤って有効にすることさえ回避するためのより良い方法を可能にするベストプラクティスはありますか?
  • gpg2を実行せずにgpg-agentを使用する方法はありますか?
  • エージェントがデーモンであり、クエリに応答できることが期待されている場合、ローカルマシンで実行されている別のユーザーまたはサービスが、キャッシュまたは保存されている資格情報にアクセスできないのはなぜですか?
9
inetknght

パスフレーズキャッシュの使用について過度に妄想していますか?私はそれについての議論を見たり、指摘されたりしたいと思います。

あなたの懸念は確かに有効なIMOです。良いニュースは、ニーズに合わせてgpg-agentの動作をカスタマイズする方法があることです。たとえば、GUIプロンプトの代わりに端末ベースのパスフレーズプロンプト(PINエントリ)を使用し、パスフレーズをnotキャッシュします。

キャッシュされたパスフレーズの使用を誤って有効にすることさえ回避するためのより良い方法を可能にするベストプラクティスはありますか?

簡単な解決策は、おそらくベストプラクティスではありませんが、次のオプションを使用して〜/ .gnupg /gpg-agent.confをカスタマイズすることです。

# Expire cached PINs (passphrases) after zero seconds
default-cache-ttl 0
max-cache-ttl 0

# If you use your GPG keys for SSH auth...
default-cache-ttl-ssh 0
max-cache-ttl-ssh 0
enable-ssh-support

# Use TTY-based PIN entry program (I see pinentry, 
# pinentry-curses, pinentry-gnome3, pinentry-tty and 
# pinentry-x11 on my system)
pinentry-program /usr/bin/pinentry-tty

私は、GPGの主要なベストプラクティスに関する次のガイド(あなたが求めているものではなく、鍵管理に関するより一般的なガイド)がかなり有益で、従うのが簡単であることに気づきました。

Gpg-agentを実行せずにgpg2を使用する方法はありますか?

私の知る限り、gpg2.xではありません。マニュアルページには次のように記載されています。

   --use-agent
   --no-use-agent
          This is dummy option. gpg always requires the agent.

私はgpg2.1.15を持っています。

エージェントがクエリに応答できることが期待されるデーモンである場合、ローカルマシンで実行されている別のユーザーまたはサービスが、キャッシュまたは保存されている資格情報にアクセスできないのはなぜですか?

良い質問...デフォルトでは、gpg-agentはソケットを使用するため、技術的には、ユーザーが理論上キーを乗っ取ることができるように実行されているすべてのプロセス。しかし、これについて私を引用しないでください。これがgpg-agentの仕組みの概要であり、本当の答えを見つけるのに役立つことを願っています: https://unix.stackexchange.com/questions/188668/how-does-gpg-agent-work

https://wiki.archlinux.org/index.php/GnuPG#Unattended_pa​​ssphrase によると、パスワードをgpgに直接提供するには、gpg-agentを実行せずに、次のオプションを使用して実行する必要があります。

gpg --passphrase-fd 0 --pinentry-mode loopback ...

このコマンドを実行した直後に、コンソールでパスワードを入力する必要があります。入力中にパスワードプロンプトは表示されませんが、入力したパスワードは表示されます。

入力中にパスワードを非表示にするには、コマンドをsttyでラップできます。

stty -echo ; gpg ... ; stty echo

これをGnuPGv。2.2.4でテストしました。gpg-agentを強制終了し、/ usr/bin/gpg-agentを細断してから、上記のように実行しました。うまくいきました。

1
cryptogopher