SSHエージェント転送を使って、サーバーへのデプロイをシンプルにすることができます。 そうすることで、キー（パスフレーズなしの！）をサーバー上に残さずに、ローカルのSSHキーを使用できます。

GitHub とやり取りするために SSH キーを既に設定している場合は、おそらく ssh-agent についてご存知でしょう。 これは、バックグラウンドで実行され、キーをメモリにロードした状態にし続けるので、キーを使うたびにパスフレーズを入力する必要がなくなります。 便利なのは、それらがサーバー上で既に動作しているかのように、サーバーからローカルの ssh-agent にアクセスさせることを選択できることです。 これは、友人のコンピュータをあなたが使えるように、友人のパスワードを友人に入力してもらうように頼むようなものです。

SSH エージェント転送の詳細については、Steve Friedl の Tech ヒント ガイドを参照してください。

SSHエージェント転送のセットアップ

SSHキーがセットアップされており、動作していることを確認してください。 まだの場合は、SSH キーの生成に関するガイドを使用できます。

ターミナルに ssh -T git@github.com を入力して、ローカル キーが機能することをテストできます。

$ ssh -T git@github.com
# Attempt to SSH in to github
> Hi USERNAME! You've successfully authenticated, but GitHub does not provide
> shell access.

いいスタートを切ることができました。 サーバーへのエージェント転送ができるよう、SSHをセットアップしましょう。

1. 任意のテキスト エディターを使用して、~/.ssh/config でファイルを開きます。 このファイルが存在しない場合は、ターミナルで touch ~/.ssh/config と入力して作成できます。

2. ファイルに次のテキストを入力し、example.com をサーバーのドメイン名または IP に置き換えます。

    Host example.com
      ForwardAgent yes
   

SSHエージェント転送のテスト

そのエージェント転送がサーバーで動作していることをテストするには、サーバーに SSH 接続し、ssh -T git@github.com をもう一度実行します。 すべてうまくいっているなら、ローカルでやった場合と同じプロンプトが返ってくるでしょう。

ローカル キーが使用されているかどうかわからない場合は、サーバー上の SSH_AUTH_SOCK 変数を調べることもできます。

$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> /tmp/ssh-4hNGMk8AZX/agent.79453

この変数が設定されていないなら、エージェント転送は動作していないということです。

$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> [No output]
$ ssh -T git@github.com
# Try to SSH to github
> Permission denied (publickey).

SSHエージェント転送のトラブルシューティング

以下は、SSHエージェント転送のトラブルシューティングの際に注意すべきことです。

コードをのチェックアウトにはSSH URLを使わなければならない

SSH転送はHTTP(s) URLでは動作せず、SSH URLでのみ動作します。 サーバー上の .git/config ファイルを確認し、URL が次のような SSH スタイルの URL であることを確認します。

[remote "origin"]
  url = git@github.com:YOUR_ACCOUNT/YOUR_PROJECT.git
  fetch = +refs/heads/*:refs/remotes/origin/*

SSHキーはローカルで動作していなければならない

エージェント転送を通じてキーを動作させるには、まずキーがローカルで動作していなければなりません。 SSH キーの生成に関するガイドは、SSH キーをローカルに設定するのに役立ちます。

システムがSSHエージェント転送を許可していなければならない

システム設定でSSHエージェント転送が許可されていないことがあります。 システム設定ファイルが使われているかは、ターミナルで以下のコマンドを入力してみればチェックできます。

$ ssh -v URL
# Connect to the specified URL with verbose debug output
> OpenSSH_8.1p1, LibreSSL 2.7.3
> debug1: Reading configuration data /Users/YOU/.ssh/config
> debug1: Applying options for example.com
> debug1: Reading configuration data /etc/ssh_config
> debug1: Applying options for *
$ exit
# Returns to your local command prompt

上記の例では、最初にファイル ~/.ssh/config が読み込まれ、次に /etc/ssh_config が読み取られます。 以下のコマンドを実行すれば、そのファイルが設定を上書きしているかを調べることができます。

$ cat /etc/ssh_config
# Print out the /etc/ssh_config file
> Host *
>   SendEnv LANG LC_*
>   ForwardAgent no

この例の /etc/ssh_config ファイルでは、エージェントの転送をブロックする方法として、特に ForwardAgent no を記述しています。 この行をファイルから削除すれば、エージェント転送は改めて動作するようになります。

サーバーはインバウンド接続でSSHエージェント転送を許可していなければならない

エージェント転送は、サーバーでブロックされているかもしれません。 サーバーへの SSH 接続および sshd_config の実行により、エージェント転送が許可されていることを確認できます。 このコマンドの出力は、AllowAgentForwarding が設定されていることを示している必要があります。

ローカルの ssh-agent が実行されている必要がある

ほとんどのコンピューターでは、オペレーティング システムによって自動的に ssh-agent が起動されます。 しかし、Windowsではこれを手動で行わなければなりません。 Git Bash を開くたびに ssh-agent を開始する方法に関するガイドがあります。

コンピューターで ssh-agent が実行されていることを確認するには、ターミナルで次のコマンドを入力します。

$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> /tmp/launch-kNSlgU/Listeners

ssh-agent がキーを使用できる必要があります。

キーが ssh-agent から見えることを確認するには、次のコマンドを実行します。

ssh-add -L

このコマンドが識別情報が利用できないと言ってきたなら、キーを追加しなければなりません。

ssh-add YOUR-KEY

ssh-add --apple-use-keychain YOUR-KEY