~/.sshGitHub への SSH 接続に使用される公開鍵と秘密鍵のペアがあります。
GitHub で SSH を適切に設定したかどうかをテストするために、 を使用しました。これは問題なく動作します。ssh -T [email protected]
また、上記のコマンドをスーパーユーザーとして実行すると、正常に動作します。
su
ssh -T [email protected]
~/.sshしかし、sudoを使用すると、コマンドが機能しません。実行時に保存されたキーペアにアクセスできないのではないかと思います。sudo
以下のコマンドは失敗します。
sudo ssh -T [email protected]
この問題はUbuntuディストリビューションでも簡単に再現でき、これGitHub ヘルプページ。
編集:
秘密鍵をssh次のように渡すことができることを理解しています。
ssh -i <path-to-private-key> -T [email protected]
を使用するとなぜ秘密鍵にアクセスできなくなるのか疑問に思います。sudo ssh -T [email protected]
答え1
仮説: 通常のユーザーに対して認証エージェントが実行されており、そのエージェントがキーを保持しています。
ssh非昇格シェルから生成されたシェルは、SSH_AUTH_SOCKエージェントと通信するためのソケットの場所を示す重要な環境変数を継承します。sshエージェントを使用できるようになります。これが通常のエージェントの使用方法です。
su変数を設定解除しません。変数のおかげでssh、after はsuソケットを見つけることができます。通常、ソケットは所有者以外のユーザーからはアクセスできませんが、現在はsshroot として実行され、root は権限に関係なく (ほぼ) すべてのファイルにアクセスできます。
sudo する変数を設定解除する（デフォルト。これそしてそれ)sshではsudo ssh …ソケットを見つけることができません。エージェントがそこにいなかったかのようです。sshのいくつかのデフォルトの場所で正しい秘密鍵を見つけようとします~/.sshが、今度は正しい秘密鍵がある通常のユーザーのホーム ディレクトリではなく、ルートのホーム ディレクトリをチェックします。
答え2
ssh に -i オプションを使用して、ID ファイルへのパスを渡すことができます。
ssh user@host -i /path/to/keyfile