Kubuntu 14.04システムでは、SSHエージェントでキーを管理しようとしていますが、どういうわけかssh-add
コマンドを無視しているようです。これを下で見てください、そして、あなたは私が意味するものを見るでしょう。
現在のキーをリストする
⟫ ssh-add -l
2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)
このキーはブート時にロードされますが、RSAではなくECDSAキーが必要でした。私はこのキーを知りません...
エージェントからキーを削除します。
⟫ ssh-add -D
All identities removed.
うん!しかし...そうですか?
⟫ ssh-add -l
2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)
なんてこったい?それはただ私にある。
何が起きてる?
⟫ env | grep -i ssh
SSH_AUTH_SOCK=/run/user/1000/keyring-eDJggO/ssh
どのプロセスがそのソケットを実行しているか見てみましょう。
⟫ Sudo fuser -u /run/user/1000/keyring-eDJggO/ssh
[Sudo] password for gert:
/run/user/1000/keyring-eDJggO/ssh: 9434(gert)
⟫ ps -p 9434 u
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
gert 9434 0.0 0.0 292528 7192 ? Sl 00:05 0:00 gnome-keyring-daemon [...]
KDEシステムでGNOMEキーリングは何をしているのですか?ここでは、KDEウォレットをSSHエージェントにするべきではありませんか?
これは答えよりも多くの質問につながり、機能しないssh-agentが残っています。
別のシステムでは、この動作を観察せず、構成の違いを見つけることができません。どちらにもKDEのみがインストールされており、インストールされているパッケージはほぼ同じです(Puppetが管理)。
注:根本的な問題を解決する答えではありません。根本原因を解決できると思われる場合は、新しい回答を提供してください。あなたは本当に私のソリューションが単なるいハックである理由を読む必要があります。
起動時に何が起こるかについて説明し、犯人を特定します。
ログインマネージャーとしてKDM(またはLightDM)を使用すると、ログイン時にXセッションが生成されます。ログインマネージャーを使用すると、システムで使用可能なセッションに基づいてXセッション(GNOME、KDE Plasmaなど)を選択できます。 /usr/share/xsessions
ディレクトリには、インストールされている各デスクトップ環境のファイルが含まれ、ユーザー固有の選択は~/.dmrc
に保存されます。
ログイン後、デスクトップ環境はロードされますが、/etc/X11/Xsession.d/
のすべてのスクリプトをロードします。 Kubuntu 14.04システムでは、デフォルトで/etc/X11/Xsession.d/90x11-common_ssh-agent
が表示され、SSHエージェントが初期化されます。予想通り。すばらしいです!
しかし実際には、さまざまなことがわかります。 gnome-keyring-daemon
はどこから来て、通常のssh-agent
はなぜ開始されないのですか?さて、GNOMEキーリングは2つの方法で開始されます。
/etc/xdg/autostart/gnome-keyring-ssh.desktop
/usr/share/upstart/sessions/gnome-keyring.conf
すべてのスクリプトは、最初に環境値をチェックして、続行するかどうかを確認します。例えば。
[ -z "$SSH_AUTH_SOCK" ] || [ -z "$GPG_AGENT_INFO" ] || { stop; exit 0; }
これにより、SSHエージェントが実際に開始される一種の競合状態になります。最初のものが勝ちます。より厄介なビットのためのブレース。
どうして1台のマシンで動作するのか信頼性の高いで、動作しないのは信頼性の高い別に? Xセッションのupstartジョブは、DESKTOP_SESSION
によって処理される/etc/upstart-xsessions
で/etc/X11/Xsession.d/00upstart
環境変数がホワイトリストに登録されている場合にのみ開始されます。 KDMを使用すると、デスクトップ環境を「デフォルト」(~/.dmrc
のdefault
)、実質的にkde-plasma
に設定できますが、kde-plasma
は表示されません。
Session=kde-plasma
を使用:
⟫ echo $DESKTOP_SESSION
kde-plasma
KDE PlasmaデスクトップでSession=default
を使用する場合:
⟫ echo $DESKTOP_SESSION
default
これは明らかに間違っています。そして、/etc/upstart-xsessions
に対するホワイトリストチェックに失敗する理由を推測できます。
killall gnome-keyring-daemon && eval `ssh-agent`
すべてのUpstartセッションジョブがまったく開始されないというバグが発生する可能性があるようです。別のバグにより、GNOMEキーリングSSHエージェントとの適切なインターフェースが妨げられます(またはssh-add
が文句を言い、失敗するはずです)。ああ、嫌いだよ、バグ。
何が正確に何をするのかを調査する時間を見つけたら、バグレポートを提出します。
今のところ、Session=default
を設定することで、Upstartのバグを「使用」し、Upstartセッションジョブが実行されないようにすることにしました。これがどれほど壊れるかはわかりませんが、これまでのところ、何もバラバラになることはありません。
根本的な原因は、そもそもGNOMEキーリングの外観であり、私にうそをついて間違ったキーを提供し続けるべきではありません。
とにかくSudo apt-get remove --purge gnome-keyringとにかく、その後再起動します。 ubuntu-ssoはそれに依存していますが、私はそれを使用しないので、心配はありません。
ssh-agentは、その後正常に機能するようです。
これは古いスレッドであることがわかります。 xubuntu 16.04を使用しています。バグはまだ残っているようです。キーを管理するためにタツノオトシゴをインストールしましたが、うまくいきました。