SSHエージェント転送を使って、サーバーへのデプロイをシンプルにすることができます。 そうすることで、キー(パスフレーズなしの!)をサーバー上に残さずに、ローカルのSSHキーを使用できます。
GitHub Enterprise Server とやりとりするための SSH キーを設定している� �合は、おそらく ssh-agent
をよく知っていることでしょう。 これは、バックグラウンドで実行され、キーをメモリにロードした状態にし続けるので、キーを使うたびにパスフレーズを入力する必要がなくなります。 便利なのは、それらがサーバー上で既に動作しているかのように、サーバーからローカルの ssh-agent
にアクセスさせることを選択できることです。 これは、友人のコンピュータをあなたが使えるように、友人のパスワードを友人に入力してもらうように� �むようなものです。
SSH エージェント転送の詳細については、Steve Friedl の Tech ヒント ガイドを参照してく� さい。
SSHエージェント転送のセットアップ
SSHキーがセットアップされており、動作していることを確認してく� さい。 ま� の� �合は、SSH キーの生成に関するガイドを使用できます。
ターミナルに ssh -T git@hostname
を入力して、ローカル キーが機能することをテストできます。
$ ssh -T git@hostname
# Attempt to SSH in to github
> Hi username! You've successfully authenticated, but GitHub does not provide
> shell access.
いいスタートを切ることができました。 サーバーへのエージェント転送ができるよう、SSHをセットアップしましょう。
-
任意のテキスト エディターを使用して、
~/.ssh/config
でファイルを開きます。 このファイルが存在しない� �合は、ターミナルでtouch ~/.ssh/config
と入力して作成できます。 -
ファイルに次のテキストを入力し、
example.com
をサーバーのドメイン名または IP に置き換えます。Host example.com ForwardAgent yes
警告: この設定をすべての SSH 接続に適用するように、Host *
のようなワイルドカードを使用したくなる� �合があります。 これはローカルの SSH キーを SSH 接続で入る すべての サーバーと共有することになるので、実際には良い考えではありません。 キーに直接アクセスされることはないかもしれませんが、接続が確立されている間は あなたと同じように それらのキーが使われるかもしれません。 追� するサーバーは、信用でき、エージェント転送で使おうとしているサーバーのみにする必要があります。
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"
# Print out the SSH_AUTH_SOCK variable
> [No output]
$ ssh -T git@hostname
# 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@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_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 yourkey
macOS では、ssh-agent
がリブート中に再起動されると、このキーを "忘れます"。 た� し、以下のコマンドでキーチェーンにSSHキーをインポートできます。
$ ssh-add -K yourkey