キーチェーン

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Keychain and the translation is 38% complete.
Outdated translations are marked like this.
Other languages:
English • ‎español • ‎français • ‎polski • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

この文書では SSH 共有鍵をキーチェーンプログラムとともに使用する方法を記述します。公開鍵暗号方式について基本的な知識を持っていることを仮定します。

Keychain is a frontend to ssh-agent and ssh-add, allowing long running sessions and letting the user enter passphases just once. It can also be used to allow scripts access to SSH connections.

背景

目下の課題

すべてのシステムに、それぞれのログインパスワードを入力する必要があるというのは、特に多数のシステムが管理されているときには不便なものです。システム管理者の中には、スクリプトまたは cron ジョブが必要とする ssh 接続を使うための簡便な方法を必要としている者もいるでしょう。いずれにせよ、この問題には解決方法があり、その第一となるものは公開鍵認証です。

公開鍵認証はどのように働くか?

あるクライアントがあるサーバの ssh デーモンに接続したいとします。クライアントはまず鍵対を生成し、サーバに公開鍵を渡します。その後、クライアントが接続を試みたときは、サーバはその公開鍵で暗号化されたチャレンジを送信します。対応する秘密鍵の所有者 (このクライアント) だけがそれを復号できるので、正しいレスポンスを返し、これにより認証が成功します。

公開鍵認証の使い方

鍵対を生成する

最初のステップは鍵対を生成することです。これを行うには、ssh-keygen コマンドを使用してください:

user $ssh-keygen

デフォルト値を採用し、強いパスフレーズを入力してください。

Warning
強いパスフレーズを選択してください。この鍵を root ログインに使用する場合は特に!

生成が終わると、秘密鍵は ~/.ssh/id_rsa に、公開鍵は ~/.ssh/id_rsa.pub に配置されているはずです。これで公開鍵を遠隔のホストにコピーする準備ができました。

Adding or changing a passphrase for the private key can be done as follows:

user $ssh-keygen -p -f ~/.ssh/id_rsa

サーバを準備する

~/.ssh/id_rsa.pub ファイルは、sshd を実行しているサーバにコピーされている必要があります。これを、遠隔サーバ上の、接続したいユーザに所属する ~/.ssh/authorized_keys ファイルに追加する必要があります。サーバへの ssh アクセスがインフラ係によって確保されたら、遠隔サーバへの公開鍵を利用した自動ログインをセットアップするために、次のステップを使用できます:

user $ssh-copy-id -i ~/.ssh/id_rsa.pub server_user@server

ssh-copy-id はこのステップのためのラッパースクリプトです。これを利用できない場合は、次のステップを利用できます:

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

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

構成をテストする

Theoretically, if all went well, and the sshd daemon on the server allows it (as this can be configured), ssh access without entering a password should now be possible on the server. The private key on the client will still need to be decrypted with the passphrase used previously, but this should not be confused with the password of the user account on the server.

user $ssh <server_user>@<server>

It should have asked for a passphrase for id_rsa, and then grant access via ssh as the user <server_user> on the server. If not, login as <server_user>, and verify that the contents of ~/.ssh/authorized_keys has each entry (which is a public key) on a single line. It is also a good idea to check the sshd configuration to make sure that it allows to use public key authorization when available.

At this point, readers might be thinking, "What's the point, I just replaced one password with another?!" Relax, the next section will show exactly how we can use this to only enter the passphrase once and re-use the (decrypted) key for multiple logins.

Making public key authentication convenient

Typical key management with ssh-agent

The next step is to decrypt the private key(s) once, and gain the ability to ssh freely, without any passwords. That is exactly what the program ssh-agent is for.

ssh-agent is usually started at the beginning of the X session, or from a shell startup script like ~/.bash_profile. It works by creating a UNIX socket, and registering the appropriate environment variables so that all subsequent applications can take advantage of its services by connecting to that socket. Clearly, it only makes sense to start it in the parent process of an X session to use the set of decrypted private keys in all subsequent X applications.

user $eval `ssh-agent`
Note
This ssh-agent will keep keys decrypted until it is killed. To set a lifetime for the keys, use the -t argument as described in man ssh-agent.

When running ssh-agent, it should output the PID of the running ssh-agent, and also set a few environment variables, namely SSH_AUTH_SOCK and SSH_AGENT_PID. It should also automatically add ~/.ssh/id_rsa to its collection and ask the user for the corresponding passphrase. If other private keys exist which need to be added to the running ssh-agent, use the ssh-add command:

user $ssh-add somekeyfile

Now for the magic. With the decrypted private key ready, ssh into a (public key configured) server without entering any passwords:

user $ssh server

In order to shut down ssh-agent (and as such require entry of the passphrase again later):

user $ssh-agent -k
Note
It is possible to have multiple ssh-agent processes running, especially when configuring it initially took some effort and trials. These processes can be killed like any other process by running killall ssh-agent.

To get even more convenience from ssh-agent, proceed to the next section on using keychain. Be sure to kill the running ssh-agent as keychain will handle the ssh-agent sessions itself.

Squeezing the last drop of convenience out of ssh-agent

Keychain will allow to reuse an ssh-agent between logins, and optionally prompt for passphrases each time the user logs in. Let's emerge it first:

root #emerge --ask net-misc/keychain

Assuming that was successful, keychain can now be used.

Add the following to the shell initialization file (~/.bash_profile, ~/.zshrc, or similar) to enable it:

FILE ~/.bash_profileキーチェーンを有効化する
keychain ~/.ssh/id_rsa
. ~/.keychain/${HOSTNAME}-sh
. ~/.keychain/${HOSTNAME}-sh-gpg
FILE ~/.zshrcEnabling Keychain in zsh
keychain ~/.ssh/id_rsa
. ~/.keychain/${HOST}-sh
. ~/.keychain/${HOST}-sh-gpg
Tip
More keys can be appended to the command line as desired. Also, to have it ask for passphrases each time a shell is spawned, add the --clear option.
Note
When not using Bash or zsh, check the EXAMPLES section of man keychain for examples of use in other shells. The idea is to get those commands to run each time a shell is used.

Now test it. First make sure the ssh-agent processes from the previous section are killed, then start up a new shell, usually by just logging in, or spawning a new terminal. It should prompt for the password for each key specified on the command line.

All shells opened after that point should reuse the ssh-agent, allowing to use passwordless SSH connections over and over.

Using keychain with Plasma 5

Plasma 5 users, instead of using ~/.bash_profile, can let Plasma manage ssh-agent for them. In order to do so, edit /etc/xdg/plasma-workspace/env/10-agent-startup.sh, which is read during Plasma's startup, and /etc/xdg/plasma-workspace/shutdown/10-agent-shutdown.sh, which is executed during its shutdown.

Here is how one could edit those files:

FILE /etc/plasma/startup/10-agent-startup.shPlasma 5 用に編集する
SSH_AGENT=true
FILE /etc/plasma/shutdown/10-agent-shutdown.shPlasma 5 用に編集する
if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

Now, all that has to be done is launch a terminal of choice, like kde-apps/konsole, and load the right set of keys to use. For example:

user $keychain ~/.ssh/id_rsa

The keys will be remembered until the end of the Plasma session (or until the ssh-agent process is killed manually).

Alternatively use KWallet with kde-plasma/ksshaskpass under Plasma 5

You can also have Plasma automatically ask you for your passphrase upon desktop login. Emerge kde-plasma/ksshaskpass, which will set up an environment variable to use the ksshaskpass application whenever ssh-add is run outside of a terminal. Then create a script as follows, and install it via the Plasma -> System Settings -> Startup and Shutdown -> Autostart.

FILE ~/ssh.shCreate ssh.sh script
#!/bin/sh
ssh-add < /dev/null
Note
Recent versions of plasma seem to require autostart scripts to have user-only permissions. You may need to chmod 700 ssh.sh before adding the script via the Autostart GUI

Concluding remarks

Security considerations

Of course, the use of ssh-agent may add a bit of insecurity to the system. If another user would gain access to a running shell, he could login to all of the servers without passwords. As a result, it is a risk to the servers, and users should be sure to consult the local security policy (if any). Be sure to take the appropriate measures to ensure the security of all sessions.

Troubleshooting

Most of this should work pretty well, but if problems do come up, then the following items might be of assistance.

  • If connecting without ssh-agent does not seem to work, consider using ssh with the -vvv options to find out what's happening. Sometimes the server is not configured to use public key authentication, sometimes it is configured to ask for local passwords anyway! If that is the case, try using the -o option with ssh, or change the server's sshd_config.
  • If connecting with ssh-agent or keychain does not seem to work, then it may be that the current shell does not understand the commands used. Consult the man pages for ssh-agent and keychain for details on working with other shells.

See also

  • SSH — リモートマシンに安全にログインし、作業を行うためのユビキタスなツールです。

External resources



This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Eric Brown, Marcelo Goes,
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.