SSHで接続したLinuxサーバー上のGNOME Keyringを、X11 Forwarding経由でSeahorseを使ってUnlockしたときのメモ。
あわせて、secret-toolでUnlockする方法と、GNOME Keyring / GCRが提供するSSH agentをSSHセッションから利用する方法も記載する。
環境
SSHのX11 Forwardingを使い、リモート側で起動したSeahorseやGNOME Keyringのパスワードプロンプトをローカル側に表示する。
まずSSH接続する。
ssh -XY server接続後、X11用の環境変数をD-Bus / systemd user session側にも反映する。
dbus-update-activation-environment --systemd DISPLAY XAUTHORITYGNOME KeyringをUnlockする
Seahorseを使う方法
Seahorseを起動する。
seahorseSeahorseが表示されたら、
Passwords → Login → Unlock
を選択し、GNOME Keyringのパスワードを入力する。
これでLogin keyringをUnlockできる。
secret-toolを使う方法
Seahorseを起動せず、secret-toolからUnlockを要求することもできる。
secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/nullKeyringがロックされている場合はUnlock用のパスワードプロンプトが表示されるので、そこでパスワードを入力する。
検索結果そのものは不要なので、標準出力は/dev/nullへ捨てている。
X11 Forwarding経由でプロンプトを表示するため、先に以下を実行しておく。
dbus-update-activation-environment --systemd DISPLAY XAUTHORITYしたがって、GUIのSeahorseを開く必要がなければ、次の手順だけでもよい。
ssh -XY server
dbus-update-activation-environment --systemd DISPLAY XAUTHORITY
secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/nullSSH agentを使う
GNOME Keyring / GCR側のSSH agentを利用する場合は、SSH_AUTH_SOCKをGCRのソケットに向ける。
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"設定後、agentに認識されている鍵を確認する。
ssh-add -l一連の操作は例えば以下になる。
ssh -XY server
dbus-update-activation-environment --systemd DISPLAY XAUTHORITY
secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -lSeahorseを使う場合は、Unlock部分を次のように置き換える。
seahorse
# Passwords → Login → Unlock毎回GCRのSSH agentを使う場合は、利用しているshellの設定ファイルなどに次を追加しておいてもよい。
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"ただし、別のssh-agentやagent forwardingを併用している場合は、既存のSSH_AUTH_SOCKを上書きすることになるため注意する。
なぜ dbus-update-activation-environment が必要なのか
SSHのX11 Forwardingを使うと、SSHセッションには例えば以下のようなDISPLAYが設定される。
localhost:10.0一方、GNOME Keyring周辺のGUIプロンプトはD-Busやsystemdのuser session経由で起動されることがある。
そのため、SSHシェル上ではDISPLAYが正しく設定されていても、D-Bus経由で起動されたプロセス側ではSSHのX11 displayを認識できない場合がある。
そこで、
dbus-update-activation-environment --systemd DISPLAY XAUTHORITYを実行して、現在のSSHセッションのDISPLAYとXAUTHORITYをactivation environment側にも渡しておく。
手順まとめ
Seahorseを使う場合。
ssh -XY server
dbus-update-activation-environment --systemd DISPLAY XAUTHORITY
seahorse
# Passwords → Login → Unlock
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -lsecret-toolを使う場合。
ssh -XY server
dbus-update-activation-environment --systemd DISPLAY XAUTHORITY
secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -l不具合時のメモ
GNOME Keyring daemonが動いているか確認する。
pgrep -af gnome-keyring-daemon挙動がおかしい場合は、user serviceを再起動する。
systemctl --user stop gnome-keyring-daemon.service
systemctl --user start gnome-keyring-daemon.serviceログをリアルタイムで確認する場合は以下。
journalctl --user-unit gnome-keyring-daemon -fe別ターミナルでこのログを流しながらSeahorseやsecret-toolを操作すると、daemon側で何が起きているか確認しやすい。
SSH agent側の確認には以下も使える。
echo "$SSH_AUTH_SOCK"
ls -l "$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -l期待するソケットは以下。
$XDG_RUNTIME_DIR/gcr/ssh補足
ssh -Xは通常のX11 Forwarding、ssh -Yはtrusted X11 Forwardingになる。
今回は、
ssh -XY serverで動作を確認した。
trusted X11 Forwardingは通常の-Xよりリモートアプリケーションに広い権限を与えるため、信頼できるサーバーに対して使用するのが前提。
また、
dbus-update-activation-environment --systemd DISPLAY XAUTHORITYは、そのユーザーのD-Bus / systemd user sessionのactivation environmentを更新する。
同じユーザーでローカルのGUIセッションも並行して利用している環境では、GUIアプリケーションの表示先に影響する可能性があるため注意する。
同様に、
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"は現在のshellから利用するSSH agentをGCR側に切り替える設定になる。
すでにOpenSSHのssh-agentやSSH agent forwardingを利用している場合、そのソケットではなくGCR側のagentを利用することになる。
結論
SSH越しにリモートマシンのGNOME KeyringをUnlockする場合は、まず
ssh -XY server
dbus-update-activation-environment --systemd DISPLAY XAUTHORITYとした上で、Seahorseから
Passwords → Login → Unlock
を実行するか、
secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/nullでUnlockを要求する。
さらにGCRのSSH agentを利用する場合は、
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -lを設定する。
GNOME Keyring daemon周辺で問題が起きた場合は、systemctl --userでの再起動とjournalctlでのログ確認が有効だった。