SSHエージェント転送の利用

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

GitHub Enterprise ServerとやりとりするためのSSHキーをセットアップ済みなら、ssh-agentには慣れていることでしょう。 これは、バックグラウンドで実行され、キーをメモリにロードした状態にし続けるので、キーを使うたびにパスフレーズを入力する必要がなくなります。 便利なのは、ローカルのssh-agentがサーバー上で動作しているかのように、サーバーからローカルのssh-agentにアクセスさせられることです。 これは、友人のコンピュータをあなたが使えるように、友人のパスワードを友人に入力してもらうように� �むようなものです。

SSHエージェント転送に関するさらに詳細な説明については、Steve Friedl's Tech Tips guideをご覧く� さい。

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

SSHキーがセットアップされており、動作していることを確認してく� さい。 ま� 確認ができていないなら、SSHキーの生成ガイドを利用できます。

ローカルのキーが動作しているかは、ターミナルでssh -T git@hostnameと入力すればテストできます。

$ ssh -T git@hostname
# SSHで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@hostnameと実行してみてく� さい。 すべてうまくいっているなら、ローカルでやった� �合と同じプロンプトが返ってくるでしょう。

ローカルのキーが使われているか確信が持てない� �合は、サーバー上でSSH_AUTH_SOCK変数を調べてみることもできます。

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

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

$ echo "$SSH_AUTH_SOCK"
# SSH_AUTH_SOCK変数の出力
> [No output]
$ ssh -T git@hostname
# SSHでgithubに入る
> Permission denied (publickey).

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

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

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

SSH転送はHTTP(s) URLでは動作せず、SSH URLでのみ動作します。 サーバー上の.git/configファイルを調べて、URLが以下のようなSSHスタイルのURLになっていることを確認してく� さい。

[remote "origin"]
  url = git@hostname:yourAccount/yourProject.git
  fetch = +refs/heads/*:refs/remotes/origin/*

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

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

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

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

$ ssh -v example.com
# Connect to example.com with verbose debug output
> OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
> 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 yourkey

$ ssh-add -K yourkey