Gentoo Linux keychainガイド

1.  背景

当面の問題

あなたはsshdを実行している立派なGentooマシンを多く持っていますが、それらのログインパスワードのすべてをタイプし続けるのは、少し不便ですよね？ もしくは、SSH接続を便利に使用する方法を必要とするスクリプトかcronジョブがあるでしょう。 いずれにせよ、この問題の解決策があります。そして、それは公開鍵認証によって始まります。

公開鍵認証の仕組み

サーバのsshdに接続したがっているクライアントがいると仮定します。 クライアントは、まず公開鍵と秘密鍵を生成し、公開鍵をサーバに置きます。 その後、クライアントが接続を試みるときはいつでも、サーバはその公開鍵で暗号化されたチャレンジを送信します。 対応する秘密鍵の所有者(クライアント)だけがそれを解読することができるので、あなたが推測するように、正しい応答を行うと認証が成功します。

2.  公開鍵認証の使用法

公開鍵と秘密鍵を生成

第一歩は公開鍵と秘密鍵を生成することです。 これを行うために、以下のようにssh-keygenコマンドを使用します。

$ ssh-keygen -t dsa
(デフォルト値で問題ありません。強力なパスフレーズを入力するようにしてください)

秘密鍵が~/.ssh/id_dsaに、公開鍵が~/.ssh/id_dsa.pubに作成されるでしょう。 これでリモートホストに公開鍵をコピーする準備ができました。

サーバの準備

sshdが実行されているサーバに~/.ssh/id_dsa.pubファイルをコピーします。 また、それをそのサーバへの接続に使用するユーザが所有する~/.ssh/authorized_keysファイルにも追加します。 以下は、既にサーバへのSSHアクセスができるならばそれを行う方法の例です。

$ scp ~/.ssh/id_dsa.pub server_user@server:~/myhost.pub
$ ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
$ ssh server_user@server "cat ~/.ssh/authorized_keys"

最後の行の出力は~/.ssh/authorized_keysファイルの内容を表示するでしょう。 それが正しいか確認してください。

設定のテスト

理論的にすべてがうまく行って、サーバのSSHデーモンがそれを許可するなら、たった今から、サーバへパスワードなしでのSSHアクセスができるはずです。 それでも、クライアント上で以前使用したパスフレーズで秘密鍵を解読する必要がありますが、これはサーバ上のユーザアカウントのパスフレーズと混同するべきではありません。

$ ssh server_user@server

うまくいけば、id_dsaのためにパスフレーズを要求され、server_userとしてサーバにSSHアクセスができるでしょう。 もしそうでなければ、server_userでログインし、~/.ssh/authorized_keysのエントリがそれぞれ一行で書かれているかを確認します。 また、公開鍵認証が利用可能であればそちらを使用するようにsshdの設定が行われているか確認した方がよいでしょう。

この時点で、もしかすると「要はどういうことなんだ？私はあるパスワードを別の物に置き換えただけなのか？！」と考えているかもしれません。 落ち着いてください。 次の章は、あなたの貴重な時間を節約するために、これをどのようにして使用するかを正確に説明します。

3.  公開鍵認証を便利にする

ssh-agentを用いた典型的な鍵の管理

ここまで従ってきたのなら、どうにかして一度秘密鍵を解読し、SSHをパスワード無しで自由に使用することができるなら、すばらしいことだと思っているかもしれません。 あなたは幸運です。すなわち、ssh-agentというプログラムがまさにこれを行ってくれるからです。

ssh-agentプログラムは通常、Xセッションの開始時か、~/.bash_profileの様なシェルスタートアップスクリプトから起動されます。 それは、unixソケットを生成し、すべてのその後のアプリケーションが、そのソケットに接続することによって、それのサービスを利用できるように、適当な環境変数を登録することによって動作します。 その通り、すべてのその後のXアプリケーションで解読された秘密鍵のセットを使用したいと思う場合にだけ、それはXセッションの親プロセスで起動するという意味になります。

$ ssh-agent

ssh-agentを起動すると、実行中のssh-agentのPIDが表示され、SSH_AUTH_SOCKとSSH_AGENT_PIDという環境変数を設定するでしょう。 それはまた自動的に収集品を~/.ssh/id_dsaに追加し、対応するパスフレーズを聞いてくるでしょう。 もし実行中のssh-agentに追加したい別の秘密鍵があるなら、ssh-addコマンドを以下のように使用します。

$ ssh-add somekeyfile

ここからがすばらしいところです。 現在あなたの解読された秘密鍵の準備ができているはずなので、パスワードを入力すること無しにサーバへSSH接続ができるでしょう。

$ ssh server

必要な時にssh-agentを終了させる方法を知っておくことは良いことですよね？

$ ssh-agent -k

ssh-agentからさらに多くの便利な機能が欲しいなら、keychainを使用する次の章に進んでください。 もしそうすると決めるなら、上記の例のように実行中の走行ssh-agentをkillするようにしてください。

ssh-agentの便利な機能を余すことなく使い切る

keychainはログイン間でssh-agentを再利用したり、任意でユーザがログインする時はいつでもパスフレーズの入力を促したりすることができます。 先に進む前に、まずそれをemergeしましょう。

# emerge keychain

成功したと仮定すると、これでkeychainを自由に使用することができます。 これを有効にするために、~/.bash_profileに以下を追加します。

keychain ~/.ssh/id_dsa
. ~/.keychain/$HOSTNAME-sh

ではテストしてみましょう。 最初に、前項でssh-agentが終了していることを確認し、そしていつものようにただログインするか、または新しいターミナルを起動することによって、新しいシェルを立ち上げます。 コマンドラインで指定した各キーのためのパスワードの入力を促されるでしょう。 その効果の後に開かれる全てのシェルはssh-agentを再利用するので、何度でもパスワードなしでSSH接続できます

KDEでkeychainを使う

あなたがKDEユーザなら、~/.bash_profileを使用する代わりに、KDEにssh-agentの管理をさせることが出来ます。 これを行うために、KDEの起動時に読み込まれる/usr/kde/${KDE_VERSION}/env/agent-startup.shと、KDEの終了時に実行される/usr/kde/${KDE_VERSION}/shutdown/agent-shutdown.shを編集する必要があります。 ${KDE_VERSION}には、インストールされているKDEのバージョンの最初の2文字が入ります。 例えば、KDE 3.5.1を使用しているのなら、これらのファイルを以下のように編集します。

if [ -x /usr/bin/ssh-agent ]; then
  eval "$(/usr/bin/ssh-agent -s)"
fi

if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

これで、あなたがすべきことは、Konsoleといったターミナルを起動し、使用したい鍵を読み込むだけです。 例えば、以下のように行います。

keychain ~/.ssh/id_dsa
(鍵のパスワードを入力)

これで、あなたの鍵は、KDEセッションを終了するか、ssh-agentを手動で強制終了するまで記憶されます。

4.  結びの言葉

安全面での配慮

もちろん、ssh-agentの使用はシステムを少し不用心にするかもしれません。 あなたがお風呂に入っている間に別のユーザがあなたのシェルを使用するなら、彼はパスワードなしであなたのサーバ全部にログインできます。 その結果、それは接続しているサーバへのリスクとなり、ローカルセキュリティポリシーを見直すようにするべきです。 それを使用するなら、あなたのセッションのセキュリティを確実にする穏当な処置を必ず取ってください。

トラブルシューティング

この大部分はかなりよく動作するはずですが、問題に出会ったなら、きっといくつかの役に立つことを知りたくなるでしょう。

• もしssh-agentなしでも接続できない場合は、sshを-vvv引数で使用して何が起きているかよく考えてください。 サーバが公開鍵認証を使用するように設定されていない時もあれば、とにかくローカルパスワードを尋ねるように設定されている時もあります。 その場合、sshを-oオプション付きで使用するか、サーバのsshd_configを変更したいでしょう。
• ssh-agentやkeychainに関する問題があるなら、もしかするとそれらが使用するコマンドを使用しているシェルが認識していないかもしれません。 他のシェルで動作させる詳細をssh-agentやkeychainのmanページを調べてください。

このドキュメントの内容は Creative Commons - Attribution / Share Alikeライセンスです。