☰

gpg-agentが奇妙に動作を停止しました。リモートシステムのエージェントがSSHソケットに接続されなくなりました。

tag-icon • tag-icon linux ssh osx gpg-agent yubikey
gpg-agentが奇妙に動作を停止しました。リモートシステムのエージェントがSSHソケットに接続されなくなりました。

リモートシステムの暗号化/暗号解読/署名およびSSHエージェントの配信にローカルシステムでyubikey nanoを使用しています。設定が本当に大変だった思い出がありますが、数ヶ月間は問題なく動作しました。突然故障しました。私の検索はすべて設定したときに読んだのと同じリンクを返しますが、停止します。

SSHエージェントの配信は何とか動作します。リモートシステムに以下が表示されます。

REMOTE:$ ssh-add -L
ssh-rsa blahblah cardno:123

SSHを使用してリモートシステムから別のサーバーにログインし、認証にnanoを使用します（プロキシ署名を有効にするにはタッチが必要なのでこれを知っています）。私のローカルシステムのgpg-agentログでSSH署名のログを見ることができます。

ただし、GPG署名/暗号化は機能しません。リモートシステムで次のコマンドを実行した場合：

REMOTE:$ echo "$(uname -a)" |  gpg2 --armor --clearsign --default-key 0x1234
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: No secret key
gpg: [stdin]: clearsign failed: No secret key

ローカルgpg-agentログには、この試行のログはありません。このコマンドを実行すると、ローカルのgpg-agentログにログエントリを表示できます。

REMOTE:$ $ netcat  -U /home/user/.gnupg/S.gpg-agent
OK Pleased to meet you
RESET
OK
GETINFO PID
ERR 67109115 Forbidden <GPG Agent>
POOP
ERR 67109139 Unknown IPC command <GPG Agent>

これにより、ローカルエージェントに次のログが生成されます。

2018-01-05 16:38:32 gpg-agent[865] DBG: chan_10 -> OK Pleased to meet you
2018-01-05 16:38:35 gpg-agent[865] DBG: chan_10 <- RESET
2018-01-05 16:38:35 gpg-agent[865] DBG: chan_10 -> OK
2018-01-05 16:38:45 gpg-agent[865] DBG: chan_10 <- GETINFO PID
2018-01-05 16:38:45 gpg-agent[865] DBG: chan_10 -> ERR 67109115 Forbidden <GPG Agent>
2018-01-05 16:39:01 gpg-agent[865] DBG: chan_10 <- POOP
2018-01-05 16:39:01 gpg-agent[865] DBG: chan_10 -> ERR 67109139 Unknown IPC command <GPG Agent>

リモートシステムのgpg-connect-agentでstrace -f -Fを実行すると、ローカルシステムから渡される~/.gnupg/のソケットではなく/var/runのソケットに接続されるようです。両方のソケットを削除し、すべてのgpg-agentプロセスを終了し、SSHリモート転送を/var/run位置または~/.gnupg位置に変更しようとしましたが、役に立ちませんでした。私が段階を台無しにしたかもしれないし、もう一度やってみますが、もしご存知の方がいらっしゃったら、次回このようなことが起きたら簡単に見つけられたらと思います。

ローカルシステム：

Mac OS X 10.11.6
gpg installed with brew
gpg (GnuPG) 2.2.1
libgcrypt 1.8.1

リモートシステム：

ubuntu 17.10
gpg (GnuPG) 2.1.15
libgcrypt 1.7.8

編集：わかりました、何が変わったのかはわかりませんが、しばらくの間そのままにしてからソケットを切り替えようとしましたが、これで動作します。

REMOTE:$ $ echo "$(uname -a)" |  strace -f -F gpg2 --armor --clearsign --default-key 0x1234
...
a bunch of garbage
...
stat("/run/user/1000/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 5

SSHリモート転送をこの新しい場所に変更しました。私は運のないgpgconf --list-dir Agent-ssh-socketが提供するソケットパスを使用する前にこれを試したと誓います。おそらく既存のエージェントを殺すことを忘れていたでしょう。結局のところ、私はこれが変更されたことを報告するブログ記事を見つけました。 https://blog.kylemanna.com/linux/gpg-213-ssh-agent-socket-moved/

ベストアンサー1

アップデート：ソケットの接続を解除してください。下部の編集内容をご覧ください。

明らかに、これには断続的なバグがあるか、これらのシステムがどのように相互作用するかによる副作用があります。私はあまりにも多くの詳細/推測に入りたくありませんが、次の点を考慮します。

  • 2番目のSSHセッションは最初のセッションのパイプに接続されます（これは何が必要ですか？）
  • REMOTEのSSHDにあるStreamLocalBindUnlinkがパイプを正しく取得できません（リモート側のプロキシがまだ開いているためですか？）。

良い回避策は、gpgエージェントを渡すために.ssh / configで別の特別なホストを使用し、そのホスト名に一度だけログインすることです！

パイプライン/実行中のエージェントとインスタンスの組み合わせによって何度も発生しましたが、非常に残念でした。新しいsshdセッションはどこにありますかいいえ新しいソケットの作成あらゆる種類の混乱を引き起こします（おそらく実行中のエージェントが古いソケットファイルを開いたままにしているため）。通常、この問題を解決しようとする時間はありません。

ついにこの問題が発生し、問題を解決して修正できました。問題を確実に再現し、解決策を示すことができます。

業務システム

REMOTE:$ echo "$(uname -a)" | gpg --armor --clearsign --default-key 0x1234
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Linux pooter 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE/0lJ/t51agRvvTILdQ2kyDf6wDYFAl9JgSYACgkQdQ2kyDf6

-----END PGP SIGNATURE-----

ローカルシステムで別のSSHまたはRsyncを実行してください。

LOCAL: $ rsync -avze ssh test.txt pooter:
bind [127.0.0.1]:5901: Address already in use

SCPは問題を引き起こしませんが、ファイルのコピー時にポート転送が失敗することを確認するため、RSYNCは明らかにsshログインを実行します。

これで、リモート暗号化/パスワードの復号化が失敗します。

REMOTE:$ echo "$(uname -a)" | gpg --armor --clearsign --default-key 0x1234
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: No secret key
gpg: [stdin]: clear-sign failed: No secret key

修正する

  1. ソケット転送を使用してすべてのSSHセッションからログアウト
  2. リモートシステム上のすべてのGPGエージェントを終了します。
  3. /var/run/xxxx/gnupg のパイプが所定の位置にあることを確認してください。
  4. パイプが消えたら、ソケット転送を使用してログインし、再生成されたことを確認してください。

ステップ3と4では、双方向に進むのがわかります。パイプが残っている場合もあり、適切に消えることもあります。パイプラインファイルを削除し、再度ログインして再作成されたことを確認する必要があるかもしれません。

これで、すべてを再暗号化/復号化できます。

アップデート - より簡単な修正

今日理由もなくこんなことが起きてイライラする。この投稿を見つけに行かなければなりませんでしたが、元の投稿で知らせていたすべてのことを実行するのは面倒です。私は上記の推測の観点からこの状況を考慮します。簡単に言うと、これはうまくいきます：

  1. Killall gpg-agent && 終了
  2. CTRL^C# 転送ポートの切断
  3. 1分ほどお待ちください
  4. 再登録

すべてが再び正常に戻った

編集：これが再び発生し、さらに1つのステップを追加しました。 Unixドメインソケットファイルを見つけて、他のシェル/ログインで次のコマンドを実行します。unlink /path/to/socket

おすすめ記事