SSH 鍵のソースを表示

[[Category:Secure Shell]]
[[en:SSH keys]]
[[es:SSH keys]]
[[it:SSH keys]]
[[ru:SSH keys]]
[[sr:SSH keys]]
[[tr:SSH_Anahtarları]]
[[zh-hans:SSH keys]]
SSH 鍵は[[Wikipedia:ja:公開鍵暗号|公開鍵暗号]]と[[Wikipedia:Challenge-response authentication|チャレンジ/レスポンス認証]]を使って SSH サーバーに自身を確認させる手段として用います。伝統的なパスワード認証と比べてこの方法を使用する利点として、ネットワークを介してパスワードを送信しなくてもサーバーから認証を受けられるということが挙げられます。パスワードを転送しているわけではないので、たとえ接続を盗聴されてもパスワードを盗まれたりクラックされる恐れがありません。さらに、SSH 鍵を使って認証をすることによって、ブルートフォース攻撃を受けるリスクを事実上なくすことができます。攻撃者が正しい証明書を得られる確率は劇的に減るからです。

セキュリティの向上につながるという他に、SSH 鍵認証は伝統的なパスワード認証よりも便利だという点もあります。SSH エージェントというプログラムを使うことで、システムごとのパスワードを記録して入力する必要はなくなり、SSH 鍵でサーバーに接続することが可能になります。

SSH 鍵に全く欠点がないというわけではなく、環境によっては相応しくないという場合もありますが、大抵の場合は SSH 鍵を使用することには強力なメリットが望めます。SSH 鍵の動作方法を理解することは、いつ、どのように鍵を使えば要求を満たせるのか考える手がかりになるでしょう。この記事では [[Secure Shell]] プロトコルについての基本的な知識を持っていて、[[公式リポジトリ]]の {{Pkg|openssh}} パッケージを既に[[インストール]]していることを前提としています。

==予備知識==
SSH 鍵は常に、一方を秘密鍵、もう一方を公開鍵としてペアで生成されます。秘密鍵はあなたしか知らない鍵で、安全に保管する必要があります。一方、公開鍵は接続したい SSH サーバーと自由に共有できます。

SSH サーバがあなたの公開鍵を持っていて、あなたが接続をリクエストしたことを確認したら、SSH サーバーは公開鍵を使ってチャレンジを作成し、あなたに送ります。このチャレンジは暗号化されたメッセージで、サーバがあなたのアクセスを許可するために、適切な応答が必要です。この暗号化されたメッセージを安全に解読できるのは秘密鍵を持っている人だけということが、暗号文を特に安全なものにしています。公開鍵を使ってメッセージを暗号化することはできる一方で、公開鍵を使ってメッセージを復号化することはできません。秘密鍵を持っている、あなただけが、チャレンジを解読して適切なレスポンスを作成することができるわけです。

この [[Wikipedia:Challenge-response authentication|チャレンジ/レスポンス認証]]は水面下で行われ、ユーザーが関知するところではありません。秘密鍵を持ってさえいれば (通常は {{ic|~/.ssh/}} ディレクトリに鍵が保存されます)、SSH クライアントはサーバーに適切なレスポンスを返すことが可能です。

秘密鍵は機密情報として考えてよく、暗号化された形式でディスクに保存することをお勧めします。暗号化された秘密鍵が必要になったとき、最初にパスフレーズを入力して秘密鍵を復号化する必要があります。これは表面的には、SSH サーバーにログインパスワードを入力するのと変わりないように見えますが、実際にはローカルシステム上の秘密鍵を復号化するためにのみ使用されます。パスフレーズはネットワーク経由で送信されることはありません。

==SSH 鍵のペアを生成==
SSH 鍵のペアは {{ic|ssh-keygen}} コマンドを実行することで生成できます。デフォルトは 3072 ビット RSA (および SHA256) で、{{man|1|ssh-keygen}} のマニュアルページには、「'''一般的に十分と見なされ'''」、事実上すべてのクライアントとサーバに互換性があるはずです。

{{hc
|$ ssh-keygen
|<nowiki>Generating public/private rsa key pair.
Enter file in which to save the key (/home/<username>/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/<username>/.ssh/id_rsa.
Your public key has been saved in /home/<username>/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:gGJtSsV8BM+7w018d39Ji57F8iO6c0N2GZq3/RY2NhI username@hostname
The key's randomart image is:
+---[RSA 3072]----+
|   ooo.          |
|   oo+.          |
|  + +.+          |
| o +   +     E . |
|  .   . S . . =.o|
|     . + . . B+@o|
|      + .   oo*=O|
|       .   ..+=o+|
|           o=ooo+|
+----[SHA256]-----+</nowiki>}}

[https://www.cs.berkeley.edu/~dawnsong/papers/randomart.pdf ランダムアートイメージ] は [https://www.openssh.com/txt/release-5.1 introduced in OpenSSH 5.1] で導入されたもので、鍵の指紋を視覚的に識別しやすくするためのものです。

{{Note|{{ic|-a}} スイッチを使うことで、パスワード暗号化の KDF ラウンドの数を指定できます。}}

{{ic|-C}} スイッチを使って公開鍵にコメントフィールドを追加して、{{ic|~/.ssh/known_hosts}} や {{ic|~/.ssh/authorized_keys}} などの場所や {{ic|ssh-add -L}} の出力で公開鍵を簡単に識別できるようにすることができます。例:

 $ ssh-keygen -C "$(whoami)@$(hostname)-$(date -I)"

上記のコマンドで、どのマシンとユーザーで作成した鍵なのか、作成日時はいつなのかというコメントが追加されます。

=== 認証鍵の種類を選択===

OpenSSH はいくつかの署名アルゴリズム (認証鍵用) をサポートしていますが、それらは利用する数学的性質によって 2つのグループに分けることができます。

# [[Wikipedia:Digital Signature Algorithm|DSA]] と [[Wikipedia:RSA (cryptosystem)|RSA]] は、2つの大きな素数の積を因数分解することの[[wikipedia:Integer factorization#Difficulty and complexity|実際的な難しさ]]に依存しています。
# 楕円曲線離散対数問題を利用した [[Wikipedia:Elliptic Curve Digital Signature Algorithm|ECDSA]] と [[Wikipedia:Curve25519|Ed25519]]。([https://www.certicom.com/content/certicom/en/52-the-elliptic-curve-discrete-logarithm-problem.html 例])

[https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ 楕円曲線暗号] (ECC) アルゴリズムは、公開鍵暗号方式に[[Wikipedia:Elliptic curve cryptography#History|最近になって追加された]]アルゴリズムです。その主な利点の一つは、[[Wikipedia:Elliptic curve cryptography#Rationale|より小さな鍵で同じレベルのセキュリティ]]を提供できることで、計算負荷の少ない操作（鍵の生成、暗号化、復号化の高速化）と、ストレージや伝送要件の低減を実現します。

OpenSSH 7.0 では、発見された脆弱性のために [https://archlinux.org/news/openssh-70p1-deprecates-ssh-dss-keys/ DSA 鍵のサポートは廃止され、無効になりました]。したがって、[[Wikipedia:cryptosystem|暗号システム]]の選択は RSA または 2 種類の ECC のうちの 1 つになります。

[[#RSA]] 鍵は最も移植性が高く、[[#Ed25519]] は最もセキュリティが高いが、クライアントとサーバの最新版が必要である[https://web.archive.org/web/20191222003107/https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html]。[[#ECDSA]]は Ed25519 より互換性が高いが(それでも RSA より劣るが)、その安全性には疑惑がある(後述)。

{{Note|鍵が使用されるのは認証を行うときだけです。強固な鍵にすることで、SSH によってデータを送信する際の CPU の負担が増えることはありません。}}

==== RSA ====

{{ic|ssh-keygen}} のデフォルトは RSA なので {{ic|-t}} オプションを指定する必要はありません。RSA はすべてのアルゴリズムの中で最高の互換性を備えていますが、十分なセキュリティを提供するためには鍵のサイズを大きくする必要があります。

鍵のサイズは最小で 1024 ビット、デフォルトは 3072 ( {{man|1|ssh-keygen}} を参照)、最大は 16384 です。

より強力な RSA 鍵ペアを生成する場合 (例えば、最先端または未知の攻撃やより高度な攻撃者から保護するため)、{{ic|-b}} オプションにデフォルトよりも高いビット値を指定するだけです。

 $ ssh-keygen -b 4096

しかし、より長い鍵を使うことには限界があることに注意してください[https://security.stackexchange.com/a/25377][https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096]。GnuPG の FAQ にはこうあります。「''RSA-2048 が提供する以上のセキュリティが必要な場合は、RSA を使い続けるのではなく、楕円曲線暗号に切り替えるほうが良いでしょう''」[https://www.gnupg.org/faq/gnupg-faq.html#please_use_ecc]。

一方、[https://web.archive.org/web/20160305203915/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml NSA Fact Sheet Suite B Cryptography] の最新版では、RSA のモジュラスを 3072 ビット以上にして、「来たるべき量子耐性アルゴリズムへの移行に''備える''」ことを提案しています。[https://www.keylength.com/en/6/]

==== ECDSA ====

楕円曲線デジタル署名アルゴリズム (ECDSA) は、[https://www.openssh.com/txt/release-5.7 in OpenSSH 5.7] で認証のための好ましいアルゴリズムとして導入されました。また、一部のベンダーは潜在的な特許の問題から、必要な実装を無効にしています。

それには、2種類の懸念があります。

# ''Political concerns'', the trustworthiness of NIST-produced curves [https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters being questioned] after revelations that the NSA willingly inserts backdoors into softwares, hardware components and published standards were made; well-known cryptographers [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 have] [https://safecurves.cr.yp.to/rigid.html expressed] [https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf doubts] about how the NIST curves were designed, and voluntary tainting has already [https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html been] [https://www.scientificamerican.com/article/nsa-nist-encryption-scandal/ proved] in the past.
# ''Technical concerns'', about the [https://blog.cr.yp.to/20140323-ecdsa.html difficulty to properly implement the standard] and the [https://www.gossamer-threads.com/lists/openssh/dev/57162#57162 slowness and design flaws] which reduce security in insufficiently precautious implementations. 

Both of those concerns are best summarized in [https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4 libssh curve25519 introduction]. Although the political concerns are still subject to debate, there is a [https://news.ycombinator.com/item?id=7597653 clear consensus] that [[#Ed25519]] is technically superior and should therefore be preferred.

==== Ed25519 ====

[https://ed25519.cr.yp.to/ Ed25519] は 2014年1月の [https://www.openssh.com/txt/release-6.5 OpenSSH 6.5] で導入されました。「''Ed25519 は ECDSA や DSA よりも優れたセキュリティと優れたパフォーマンスを提供する楕円曲線署名方式です''」。その主な強みは、その速度、一定時間の実行時間(およびサイドチャネル攻撃への耐性)、そして曖昧なハードコードされた定数がないことです[https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt]。動作方法については、Mozilla の開発者による[https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/ このブログ記事] も参照してください。

これはすでに[[Wikipedia:Curve25519#Popularity|多くのアプリケーションやライブラリ]]で実装されており、OpenSSH の[https://www.libssh.org/2013/11/03/openssh-introduces-curve25519-sha256libssh-org-key-exchange/ デフォルトの鍵交換アルゴリズム](鍵署名とは異なります)です。

Ed25519 の鍵ペアは以下の方法で生成できます。

 $ ssh-keygen -t ed25519

すべての Ed25519 鍵は 256 ビットなので、鍵のサイズを設定する必要はありません。

古い SSH クライアントやサーバは、この鍵に対応していないかもしれないことに注意してください。

==== FIDO/U2F ====

FIDO/[[U2F]] [[Wikipedia:Security Tokens|ハードウェア認証機能]]のサポートが [https://www.openssh.com/txt/release-8.2 OpenSSH バージョン 8.2] で追加され、上記の楕円曲線署名方式のいずれにも対応しました。これは USB やその他の手段で接続されたハードウェアトークンを、 秘密鍵と並ぶ第二の要素として機能させることができるようにするものです。

{{Note|クライアントとサーバーの両方が {{ic|ed25519-sk}}と {{ic|ecdsa-sk}} の鍵タイプに対応している必要があります。}}

ハードウェアトークンサポートのため、{{Pkg|libfido2}} が必要です。

{{Note|OpenSSH はハードウェアトークンとの通信にミドルウェアライブラリを使用し、USB トークンをサポートする内部ミドルウェアが付属しています。その他のミドルウェアは {{man|5|sshd_config|SecurityKeyProvider}} ディレクティブや、{{ic|ssh-keygen}} および {{ic|ssh-add}} の {{ic|SSH_SK_PROVIDER}}  環境変数で指定することが可能です。}}

互換性のある FIDO 鍵を添付した後、鍵ペアを生成することができる。

 $ ssh-keygen -t ed25519-sk

通常、生成の確認のため、PIN の入力やトークンのタップが必要になります。サーバに接続する場合は、生成時に {{ic|-O no-touch-required}} コマンドラインオプションを使用し、サーバで {{man|8|sshd|no-touch-required}} {{ic|authorized_keys}} オプションが設定されていない限り、通常トークンをタップする必要があります。

To create keys that do not require touch events, generate a key pair with the {{ic|no-touch-required}} option. For example:

 $ ssh-keygen -O no-touch-required -t ed25519-sk

{{Note|すべてのハードウェアトークンがこのオプションに対応しているわけではありません。YubiKey を使用している場合、ed25519-sk の鍵タイプにはファームウェアのバージョン 5.2.3 が必要です。[https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-2-3/]}}

Additionally, {{ic|sshd}} rejects {{ic|no-touch-required}} keys by default. To allow keys generated with this option, either enable it for an individual key in the {{ic|authorized_keys}} file,

 no-touch-required sk-ssh-ed25519@openssh.com AAAAInN... user@example.com

or for the whole system by editing {{ic|/etc/ssh/sshd_config}} with

 PubkeyAuthOptions none

An ECDSA-based keypair may also be generated with the {{ic|ecdsa-sk}} keytype, but the relevant concerns in the [[#ECDSA]] section above still apply.

 $ ssh-keygen -t ecdsa-sk

===鍵の場所とパスフレーズを選択===
{{ic|ssh-keygen}} コマンドの実行時に、秘密鍵の名前と保存場所について尋ねられます。デフォルトでは、鍵は {{ic|~/.ssh/}} ディレクトリに保存され、名前は使用する暗号化のタイプに合わせて付けられます。この記事に出てくるサンプルコードをそのまま使用できるようにするため、デフォルトの名前と場所を使うことを推奨します。

パスフレーズを求められたら、秘密鍵のセキュリティを考慮して推測が困難なものを入力してください。一般的には長くてランダムなパスワードの方が強度が高く、悪意ある人の手に渡っても解読されにくいでしょう。

パスフレーズを設定しないで秘密鍵を作成することも可能です。パスフレーズが不要なことは便利である一方、リスクも伴うということを理解してください。パスフレーズを設定しなかった場合、秘密鍵はディスク上に平文で保存されることになります。秘密鍵ファイルにアクセスすることさえできれば、誰でも (鍵を使って認証を行っている) SSH サーバーの認証を掻い潜ることができてしまいます。さらに、パスフレーズを設定しないということは、root ユーザーを無条件で信頼することになります。root ユーザーはファイルのパーミッションを回避していつでも秘密鍵ファイルにアクセスすることができます。

{{Note|以前は、秘密鍵のパスワードは安全でない方法でエンコードされていました: MD5 ハッシュの一回分だけです。OpenSSH 6.5 以降では、秘密鍵をエンコードするための新しい、より安全な形式を サポートしています。この形式は [https://www.openssh.com/txt/release-7.8 OpenSSH version 7.8] 以降のデフォルトです。Ed25519 の鍵は常に新しいエンコーディング形式を使用しています。新しい形式にアップグレードするには、次のセクションで説明するように、 鍵のパスフレーズを変更するだけです。}}

====鍵を変更せずに秘密鍵のパスフレーズを変更する====
最初に作成した SSH 鍵のパスフレーズが好ましくない、あるいは変更しなくてはならない場合、{{ic|ssh-keygen}} コマンドを使うことで、実際の鍵を変更することなくパスフレーズを変更することができます。これは、パスワードのエンコード形式を新しい標準に変更するためにも使用できます。

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

====複数の鍵の管理====

複数の SSH ID がある場合、設定内で {{ic|Match}} および {{ic|IdentityFile}} ディレクティブを使用して、異なるホストまたはリモートユーザーに使用する異なる鍵を設定することができます。

{{hc|~/.ssh/config|2=
Match host=SERVER1
   IdentitiesOnly yes
   IdentityFile ~/.ssh/id_rsa_IDENTITY1

Match host=SERVER2,SERVER3
   IdentitiesOnly yes
   IdentityFile ~/.ssh/id_ed25519_IDENTITY2
}}

他のオプションについては、{{man|5|ssh_config}} を参照してください。

==== SSH 鍵をハードウェアトークンに保存する ====

SSH 鍵は、スマートカードや USB トークンなどのセキュリティ・トークンに保存することも可能です。この場合、秘密鍵はディスクに保存されるのではなく、トークン上に安全に保存されるという利点があります。セキュリティ・トークンを使用する場合、機密性の高い秘密鍵が PC の RAM 上に存在することはなく、暗号化処理はトークン自体で実行されます。また、暗号化トークンは、1 台のパソコンに縛られることなく、簡単にパソコンから取り外して持ち運び、他のパソコンで使用することができるという利点もあります。

ハードウェアトークンの例としては、以下のようなものがあります。

* [[YubiKey#SSH notes]] FIDO/U2F 鍵の OpenSSH ネイティブサポート
* [[YubiKey#SSH keys]]
* [[Trusted Platform Module#SSH 鍵のセキュア化]]

==リモートサーバーに公開鍵をコピー==
鍵ペアを生成したら、公開鍵をリモートサーバーにコピーして、SSH 鍵認証が使えるようにする必要があります。公開鍵のファイル名は秘密鍵のファイル名に {{ic|.pub}} 拡張子を付けたものになります。秘密鍵は共有せず、ローカルマシンに残しておくようにしてください。

===シンプルな方法===

{{Note|1=この方法はリモートサーバーが {{ic|sh}} 以外のシェル ({{ic|tcsh}} など) をデフォルトで使っている場合や OpenSSH が 6.6.1p1 より古い場合は失敗します。[https://bugzilla.redhat.com/show_bug.cgi?id=1045191 このバグレポート] を参照。}}

鍵のファイルが {{ic|~/.ssh/id_rsa.pub}} の場合、次のコマンドを実行します。
 $ ssh-copy-id remote-server.org

リモートマシンでユーザー名が異なる場合、サーバーの名前の前に {{ic|@}} とユーザー名を書きます。
 $ ssh-copy-id username@remote-server.org

公開鍵のファイル名がデフォルトの {{ic|~/.ssh/id_rsa.pub}} ではない場合、{{ic|/usr/bin/ssh-copy-id: ERROR: No identities found}} というエラーが表示されます。その場合、公開鍵の場所を明示してください。
 $ ssh-copy-id -i ~/.ssh/id_ecdsa.pub username@remote-server.org

ssh サーバーがデフォルトの22番ポート以外を使っている場合、ポート番号を付して下さい。
 $ ssh-copy-id -i ~/.ssh/id_ecdsa.pub -p 221 username@remote-server.org

=== 手動方法 ===

デフォルトで、OpenSSH では、公開鍵は {{ic|~/.ssh/authorized_keys}} と連結する必要があります。まず公開鍵をリモートサーバーにコピーしてください。

 $ scp ~/.ssh/id_ecdsa.pub username@remote-server.org:

上記の例では {{ic|scp}} によって公開鍵 ({{ic|id_ecdsa.pub}}) をリモートサーバーのホームディレクトリにコピーしています。サーバーアドレスの最後にはかならず {{ic|:}} を付けるのを忘れないで下さい。また、必要に応じて上記の例にある公開鍵の名前は置き換えるようにしてください。

リモートサーバー側では、(ディレクトリが存在しない場合) {{ic|~/.ssh}} ディレクトリを作成して {{ic|authorized_keys}} ファイルに公開鍵を追記する必要があります。

 $ ssh username@remote-server.org
 username@remote-server.org's password:
 $ mkdir ~/.ssh
 $ chmod 700 ~/.ssh
 $ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys
 $ rm ~/id_ecdsa.pub
 $ chmod 600 ~/.ssh/authorized_keys

最後の2つのコマンドではサーバーから公開鍵ファイルを削除して、{{ic|authorized_keys}} ファイルにパーミッションを設定して、所有者である貴方以外のユーザーが読み書きできないようにしています。

==SSH エージェント==
秘密鍵をパスフレーズで暗号化した場合、公開鍵認証を使って SSH サーバーに接続するたびに設定したパスフレーズを入力する必要があります。認証を進める前に秘密鍵を復号化するために {{ic|ssh}} や {{ic|scp}} が呼ばれるたびにパスフレーズが求められるのです。

SSH エージェントは復号化された秘密鍵をキャッシュして、あなたに代わって SSH クライアントプログラムに鍵を提出します。この場合、パスフレーズを入力するのは一度だけでよく、その時に秘密鍵がエージェントのキャッシュに追加されます。これは頻繁に SSH 接続を行う場合にとても便利です。

大抵、エージェントはログイン時に自動的に実行されるように設定され、ログインセッションの間はずっと実行し続けます。この効果を得るのに様々なエージェント、フロントエンド、設定が存在します。このセクションでは様々なソリューションを並べているので、必要に応じて選びとるようにしてください。

===ssh-agent===
ssh-agent は OpenSSH に含まれているデフォルトのエージェントです。直接使用することもできますし、後のセクションで触れている、フロントエンドのためのバックエンドとして使うこともできます。{{ic|ssh-agent}} が実行されると、ssh-agent は自分をバックグラウンドにフォークして、使用する環境変数を出力します。

{{hc|$ ssh-agent|2=
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2148; export SSH_AGENT_PID;
echo Agent pid 2148;
}}

これらの変数を利用するには、{{ic|eval}} コマンドを通してコマンドを実行してください。

{{hc|$ eval $(ssh-agent)|
Agent pid 2157
}}

{{Tip|上記のコマンドを {{ic|~/.bash_profile}} スクリプトに追加すればログインシェルが起動した時に自動で実行されます。}}

{{ic|ssh-agent}} を実行したら、秘密鍵をキャッシュに追加する必要があります:

{{hc|$ ssh-add ~/.ssh/id_ecdsa|
Enter passphrase for /home/user/.ssh/id_ecdsa:
Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)
}}

秘密鍵が暗号化されている場合、{{ic|ssh-add}} はパスフレーズを入力するように要求します。秘密鍵がエージェントに追加されたら、パスフレーズを入力することなく SSH 接続を行うことができるようになります。

{{Tip|{{ic|git}} を含むすべての {{ic|ssh}} クライアントが、初回使用時に鍵をエージェントに保存するようにするには、{{ic|~/.ssh/config}} に {{ic|AddKeysToAgent yes}} という設定項目を追加してください。他に指定できる値は {{ic|confirm}}、{{ic|ask}} および {{ic|no}} (デフォルト) です。}}

鍵が必要になるまでパスフレーズの入力をしないようにするには、以下を {{ic|~/.bashrc}} に追加します:

 <nowiki>if ! pgrep -u $USER ssh-agent > /dev/null; then
    ssh-agent > ~/.ssh-agent-thing
fi
if [[ "$SSH_AGENT_PID" == "" ]]; then
    eval $(<~/.ssh-agent-thing)
fi
ssh-add -l >/dev/null || alias ssh='ssh-add -l >/dev/null || ssh-add && unalias ssh; ssh'</nowiki>

{{ic|ssh-agent}} プロセスが存在しない場合にプロセスが実行され、出力が保存されます。プロセスが既に存在する場合、キャッシュされた {{ic|ssh-agent}} の出力を取得して必要な環境変数を設定します。また、必要なときは、{{ic|ssh}} にエイリアスを作成してエージェントに鍵を追加し、それからエイリアスを削除します。この方法の欠点は {{ic|git}} など、{{ic|ssh}} 以外の秘密鍵を使用するコマンドでは鍵は追加されないということです。

後で述べるように、この問題を回避できる {{ic|ssh-agent}} のフロントエンドや代替エージェントも多数存在します。

====systemd ユーザーで ssh-agent を起動====

[[systemd/ユーザー]]機能を使ってエージェントを起動することができます。{{ic|~/.config/systemd/user}} フォルダに以下のユニットファイルを配置してください:

{{hc|~/.config/systemd/user/ssh-agent.service|<nowiki>
[Unit]
Description=SSH key agent

[Service]
Type=forking
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -a $SSH_AUTH_SOCK

[Install]
WantedBy=</nowiki>''default''.target
}}

{{ic|1=export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"}} をシェルのスタートアップファイルに追加してください。例えば [[Bash]] の場合 {{ic|.bash_profile}} です。その後、サービスを有効化・起動してください。

====ssh-agent をラッパープログラムとして使う====
ssh-agent を (X セッションごとに) 起動する別の方法は [http://upc.lbl.gov/docs/user/sshagent.shtml UC Berkeley Labs による ssh-agent チュートリアル] に載っています。{{ic|startx}} コマンドで X を起動する場合に、以下のように {{ic|ssh-agent}} を {{ic|startx}} の前に付けることができます:

 $ ssh-agent startx

そのため、考える必要もなく、{{ic|.bash_aliases}} ファイルまたは同等のファイルにエイリアスを置くことができます。

 alias startx='ssh-agent startx'

このようにすることで、ログインセッション間で余計な {{ic|ssh-agent}} インスタンスが浮遊する問題を回避することができます。まさに1つのインスタンスが、X セッション全体と共存し、死んでいくのです。

{{note|ssh-agent startx を呼び出す代わりに、{{ic|~/.xinitrc}} に {{ic|eval $(ssh-agent)}}を追加することもできます。}}

鍵をエージェントに即座に追加する方法については、以下の  [[#ssh-add で x11-ssh-askpass を呼び出す]]を参照してください。

===GnuPG エージェント===

[[gpg-agent]] は OpenSSH エージェントプロトコルエミュレーションを持っています。必要な設定については、[[GnuPG#SSH エージェント]] を参照してください。

===Keychain===
[http://www.funtoo.org/Keychain Keychain] は出来る限りユーザーの手を煩わせることなく SSH 鍵の管理を楽にするために作られたプログラムです。''ssh-agent'' と ''ssh-add'' の両方を動かすシェルスクリプトとして実装されています。Keychain の特徴として、複数のログインセッションで単一の ''ssh-agent'' プロセスを維持することができます。したがって、パスフレーズを入力するのはマシンを起動したときだけで済みます。

==== インストール ====

{{Pkg|keychain}} パッケージを[[インストール]]してください。

==== 設定 ====

{{Warning|2015-09-26 現在 {{ic|-Q, --quick}} オプションには、再ログイン時に ''keychain'' が新しく生成された ''ssh-agent'' に切り替わるという予期せぬ副作用があり(少なくとも [[GNOME]] を使用しているシステムでは)、以前に登録した鍵をすべて再入力しなければなりません}}

[[シェル]]の設定ファイルに以下のような行を追加してください。例えば、[[Bash]] を使用している場合。

{{hc|~/.bashrc|
eval $(keychain --eval --quiet id_ed25519 id_rsa ~/.keys/my_custom_key)
}}

{{Note|{{ic|~/.bashrc}} が上流で推奨されている {{ic|~/.bash_profile}} の代わりに使われているのは、Arch ではログインシェルと非ログインシェルの両方で source されるため、テキストとグラフィックの両方の環境に適しているからです。これらの違いについては、[[Bash#実行]]を参照してください。}}

上記の例では

* {{ic|--eval}} スイッチは、最初の {{ic|eval}} コマンドで評価される行を出力します。これにより、ssh クライアントがエージェントを見つけるために必要な環境変数が設定されます。
* {{ic|--quiet}} は出力を警告、エラー、ユーザープロンプトに制限します。

例にあるように、コマンドラインで複数の鍵を指定できます。keychain はデフォルトで {{ic|~/.ssh/}} ディレクトリ内の鍵ペアを検索しますが、標準的でない場所にある鍵には絶対パスを指定します。また、{{ic|--confhost}} オプションを使用して、{{ic|~/.ssh/config}} で特定のホストに定義された {{ic|IdentityFile}} 設定を検索し、これらのパスを使用して鍵を探すように keychain に通知することもできます。

他のシェルでの  ''keychain'' の設定については、{{ic|keychain --help}} または {{man|1|keychain}} を参照してください。

Keychain をテストするには、新しいターミナルエミュレータを開くか、ログアウトしてセッションに戻ります。すると、{{ic|$SSH_ASKPASS}} で設定したプログラムを使って、あるいはターミネル上で、指定した鍵のパスフレーズを入力するように求められます。

Keychain は連続ログイン時に同じ ''ssh-agent'' プロセスを再利用するため、次回ログイン時や新しい端末を開いたときにパスフレーズを入力する必要はありません。パスフレーズの入力は、マシンを再起動するたびに一度だけ行われます。

==== Tips ====

* ''keychain'' は、公開鍵ファイルが秘密鍵と同じディレクトリに存在し、拡張子が {{ic|.pub}} であることを期待します。秘密鍵がシンボリックリンクの場合、公開鍵はシンボリックリンクと一緒に、またはシンボリックリンクのターゲットと同じディレクトリにあります (この機能を使用するには、システム上で {{ic|readlink}} コマンドが使用可能であることが必要です)。

* グラフィカルプロンプトを無効にして、常に端末上でパスフレーズを入力する場合は、{{ic|--nogui}} オプションを使用します。これにより、例えばパスワードマネージャから長いパスフレーズをコピーペーストすることができます。

* 鍵のロック解除をすぐに要求されるのではなく、必要な時まで待ちたい場合は、{{ic|--noask}} オプションを使用します。

{{Note|Keychain は [[GPG]] の鍵も同じように管理することができます。デフォルトでは ''ssh-agent'' のみを起動しようとしますが、 {{ic|--agents}} オプションを使ってこの動作を変更することができます (例: {{ic|--agents ssh,gpg}})。{{man|1|keychain}} を参照してください。}}

===x11-ssh-askpass===

{{pkg|x11-ssh-askpass}} パッケージは、X セッションを実行する際にパスフレーズを入力するためのグラフィカルなダイアログを提供します。''x11-ssh-askpass'' は {{pkg|libx11}} と {{pkg|libxt}} ライブラリのみに依存し、''x11-ssh-askpass'' の外観はカスタマイズが可能です。このプログラムは ''ssh-add'' プログラムによって起動され、復号化された鍵を [[#ssh-agent|ssh-agent]] にロードしますが、次の手順では、前述の [[#Keychain|Keychain]]  スクリプトによって ''x11-ssh-askpass'' が起動されるように設定します。

{{Pkg|keychain}} と {{Pkg|x11-ssh-askpass}} をインストールしてください。どちらも[[公式リポジトリ]]に入っています。

{{ic|~/.xinitrc}} ファイルを編集し、以下の行を追加します。必要であれば、秘密鍵の名前と場所を置き換えてください。これらのコマンドは、必ずウィンドウマネージャを起動する行の '''前''' に記述してください。

{{hc|~/.xinitrc|
keychain ~/.ssh/id_ecdsa
[ -f ~/.keychain/$HOSTNAME-sh ] && . ~/.keychain/$HOSTNAME-sh 2>/dev/null
[ -f ~/.keychain/$HOSTNAME-sh-gpg ] && . ~/.keychain/$HOSTNAME-sh-gpg 2>/dev/null
...
exec openbox-session}}

上記の例では、1行目で ''keychain'' を起動し、秘密鍵の名前と場所を渡しています。もし ''keychain'' の起動が初めてでなければ、次の2行で  {{ic|$HOSTNAME-sh}} と {{ic|$HOSTNAME-sh-gpg}} の内容を読み込みます（存在する場合）。これらのファイルには、以前の ''keychain'' のインスタンスの環境変数が保存されています。

====ssh-add で x11-ssh-askpass を呼び出す====

''ssh-add'' のマニュアルページでは、{{ic|DISPLAY}} 変数の定義に加えて、{{ic|SSH_ASKPASS}} にあなたの askpass プログラムの名前 (この場合 ''x11-ssh-askpass'') を設定する必要があることを明記しています。Arch Linux のデフォルトインストールでは、x11-ssh-askpass のバイナリは {{ic|/usr/lib/ssh/}} に置かれ、ほとんどの人の {{ic|PATH}} には入っていないことに留意してください。これは {{ic|SSH_ASKPASS}} 変数を宣言するときだけでなく、テーマ設定するときにも少し面倒です。どこでもフルパスを指定しなければならないのです。この2つの不都合はシンボリックリンクによって同時に解決することができます。

 $ ln -sv /usr/lib/ssh/x11-ssh-askpass ~/bin/ssh-askpass

これは {{ic|~/bin}} が {{ic|PATH}} に入っていると仮定しています。これで {{ic|.xinitrc}} でウィンドウマネージャを呼び出す前に、環境変数 {{ic|SSH_ASKPASS}} を書き出すだけでよくなりました。

 $ export SSH_ASKPASS=ssh-askpass

といったものが [[X resources]] に含まれることになります。

 ssh-askpass*background: #000000

この方法は、[[#ssh-agent をラッパープログラムとして使う|上記の ''ssh-agent'' をラッパー・プログラムとして使う]]方法とうまく連動しています。{{ic|ssh-agent startx}} で X を起動し、ssh-add をウィンドウマネージャのスタートアッププログラムのリストに追加します。

====テーマ====
''x11-ssh-askpass'' ダイアログの外観は [[X resources]] を設定することでカスタマイズできます。''x11-ssh-askpass'' の [http://www.jmknoble.net/software/x11-ssh-askpass/ ホームページ] にはいくつか [http://www.jmknoble.net/software/x11-ssh-askpass/screenshots.html サンプルテーマ] が挙げられています。詳しくは ''x11-ssh-askpass'' のマニュアルページを見て下さい。

====他のパスフレーズダイアログ====
''x11-ssh-askpass'' の代わりに他のパスフレーズダイアログプログラムを使うこともできます:

* {{Pkg|ksshaskpass}} は公式リポジトリからインストールできます。{{AUR|kdelibs}} に依存しており [[KDE]] デスクトップ環境にうってつけです。

* {{Pkg|openssh-askpass}} は {{AUR|qt4}} ライブラリに依存しており公式リポジトリからインストールできます。

===pam_ssh===
[http://pam-ssh.sourceforge.net/ pam_ssh] プロジェクトは SSH 秘密鍵の [[Wikipedia:Pluggable authentication module|Pluggable Authentication Module]] (PAM) を提供しています。このモジュールを使うことで SSH 接続のシングルサインオンができます。ログイン時に、伝統的なシステムパスワードの代わりに、もしくはそれに加えて、SSH 秘密鍵のパスフレーズを入力することができます。認証が完了したら、pam_ssh モジュールは ssh-agent を生成して復号化された秘密鍵をセッションの間だけ保存します。

tty ログインプロンプトでシングルサインオンを有効にしたいときは、[[Arch User Repository]] から非公式の {{AUR|pam_ssh}} パッケージをインストールしてください。

{{Note|pam_ssh 2.0 では認証プロセスに使用する秘密鍵を {{ic|~/.ssh/login-keys.d/}} 下に配置する必要があります。}}

秘密鍵ファイルのシンボリックリンクを作成して {{ic|~/.ssh/login-keys.d/}} に配置します。以下の例の {{ic|id_rsa}} をあなたの秘密鍵ファイルの名前に置き換えて下さい:

 $ mkdir ~/.ssh/login-keys.d/
 $ cd ~/.ssh/login-keys.d/
 $ ln -s ../id_rsa

{{ic|/etc/pam.d/login}} ファイルを編集して以下の例で太字でハイライトされているテキストを記述してください。これらの行の順番は重要で、ログインに影響します。

{{Warning|PAM の設定を誤ると、システムがすべてのユーザーがロックアウトされた状態になる可能性があります。 変更を加える前に、PAM 設定がどのように機能するかを理解し、ロックアウトされて変更を元に戻す必要がある場合に備えて、Arch LiveCD などの PAM 設定ファイルにアクセスするためのバックアップ手段を理解しておく必要があります。 PAM 設定をさらに詳細に説明する IBMdeveloperWorks の[https://www.ibm.com/developerworks/linux/library/l-pam/index.html 記事]が利用可能です。}}

{{hc|/etc/pam.d/login|2=
#%PAM-1.0

auth       required     pam_securetty.so
auth       requisite    pam_nologin.so
auth       include      system-local-login
'''auth       optional     pam_ssh.so        try_first_pass'''
account    include      system-local-login
session    include      system-local-login
'''session    optional     pam_ssh.so'''
}}

上記の例では、最初にログイン認証が通常通り行われ、ユーザーパスワードの入力が促されます。認証スタックの最後に追加された {{ic|auth}}  認証ルールは、{{ic|~/.ssh/login-keys.d}} ディレクトリにある秘密鍵の復号化を試みるよう、 pam_ssh モジュールに指示を出します。{{ic|try_first_pass}} オプションは pam_ssh モジュールに渡され、以前に入力されたユーザーパスワードを使用して SSH 秘密鍵を最初に復号化しようとするように指示します。ユーザーの秘密鍵のパスフレーズとユーザーパスワードが同じであれば、これは成功し、ユーザーは同じパスワードを 2 回入力するように要求されることはないはずです。秘密鍵のパスフレーズとユーザーパスワードが異なる場合、pam_ssh モジュールはユーザーパスワードの入力後に SSH パスフレーズを入力するようユーザーに促します。{{ic|optional}} 制御値は、SSH 秘密鍵を持たないユーザーでもログインできるようにします。このように、pam_ssh の使用は、SSH 秘密鍵を持たないユーザーには透過的になります。

[[SLiM]] や [[XDM]] のような X11 ディスプレイマネージャのような他のログイン手段を使用し、同様の機能を提供させたい場合、関連する PAM 設定ファイルを同様の方法で編集する必要があります。PAM をサポートしているパッケージは、通常 {{ic|/etc/pam.d/}} ディレクトリにデフォルトの設定ファイルを配置します。

pam_ssh の使用方法の詳細とオプションの一覧は {{man|8|pam_ssh|url=}} の man ページにあります。

==== SSH 鍵のロック解除に別のパスワードを使用する ====

鍵のパスフレーズを使うか、（異なる）ログインパスワードを使うかによって、SSH 鍵を解除するかしないかを決めたい場合は、{{ic|/etc/pam.d/system-auth}} を以下のように変更します。

{{hc|/etc/pam.d/system-auth|2=
#%PAM-1.0

'''auth      [success=1 new_authtok_reqd=1 ignore=ignore default=ignore]  pam_unix.so     try_first_pass nullok'''
'''auth      required  pam_ssh.so      use_first_pass'''
auth      optional  pam_permit.so
auth      required  pam_env.so

account   required  pam_unix.so
account   optional  pam_permit.so
account   required  pam_time.so

password  required  pam_unix.so     try_first_pass nullok sha512 shadow
password  optional  pam_permit.so

session   required  pam_limits.so
session   required  pam_unix.so
session   optional  pam_permit.so
'''session   optional  pam_ssh.so'''
}}

説明については、[https://unix.stackexchange.com/a/239486]を参照してください。

====pam_ssh の既知の問題====
pam_ssh プロジェクトの作業は頻繁には行われず、提供される文書もまばらです。パッケージ自体には記載されていない制限事項があることを認識しておく必要があります。

* pam_ssh のバージョン 2.0 より前のものは、ECDSA (楕円曲線) 暗号の新しいオプションを採用した SSH 鍵をサポートしていません。もし、それ以前のバージョンの pam_ssh を使っているならば、RSA か DSA 鍵を使わなければなりません。
* pam_ssh によって生成された {{ic|ssh-agent}} プロセスは、ユーザログインの間持続しません。[[GNU Screen]] セッションをログイン後もアクティブにしておきたい場合、 Screen セッションに再接続すると、ssh-agent と通信できなくなることに気づくかもしれません。これは、GNU Screen 環境とその子環境は、GNU Screen が起動されたときに存在していた ssh-agent のインスタンスをまだ参照しており、以前のログアウトで強制終了されたからです。[[#Keychain|Keychain]] フロントエンドは、ログインの間 ssh-agent プロセスを存続させることでこの問題を回避しています。

=== pam_exec-ssh ===

[[#pam_ssh|pam_ssh]] の代わりに {{AUR|pam_exec-ssh}} を使うことができます。これは
pam_exec を使うシェルスクリプトです。設定に関するヘルプは [https://github.com/x70b1/pam_exec-ssh アップストリーム]にあります。

===GNOME Keyring===
[[GNOME]] デスクトップを使用する場合、[[GNOME Keyring]] ツールを SSH エージェントとして使うことができます。詳しくは [[GNOME Keyring]] の記事を見て下さい。

===Kwallet を使って SSH 鍵を保存===
kwallet を使って SSH 鍵を保存する方法は、[[KDE Wallet#KDE ウォレットを使って ssh 鍵のパスフレーズを保存]]を見て下さい。

===KeePass2 と KeeAgent プラグイン===

[http://lechnology.com/software/keeagent/ KeeAgent] は [[KeePass]] のプラグインで、SSH 鍵を KeePass データベースに保存することができ、他のプログラムから SSH 認証に使用されます。

* PuTTY と OpenSSH の秘密鍵フォーマットをサポート。
* Linux/Mac のネイティブの SSH エージェントと Windows の PuTTY で動作。

[[KeePass#プラグインのインストール]]を見て、{{Pkg|keepass-plugin-keeagent}} パッケージを[[インストール]]してください。新しい機能が早く追加されるベータ版も存在します: {{AUR|keepass-plugin-keeagent-beta}}{{Broken package link|パッケージが存在しません}}。

=== KeePassXC ===

KeePass の KeePassXC フォークは [https://keepassxc.org/docs/#faq-ssh-agent-how デフォルトで SSH エージェントとしての使用をサポートしています]。また、KeeAgent のデータベース形式とも互換性があります。

==トラブルシューティング==

=== サーバーによって無視される鍵 ===

SSH サーバーが鍵を無視しているように見える場合は、関連するすべてのファイルに適切なパーミッションが設定されていることを確認してください。<br />ローカルマシンの場合:

 $ chmod 700 ~/.ssh
 $ chmod 600 ~/.ssh/key

リモートマシンの場合:

 $ chmod 700 ~/.ssh
 $ chmod 600 ~/.ssh/authorized_keys

リモートマシンの場合は、ターゲットユーザーのホームディレクトリに正しいアクセス許可があることも確認します（グループなどが書き込み可能であってはなりません）。

 $ chmod go-w /home/target_user

* パーミッションの設定で問題が解決しないときは {{ic|sshd_config}} で {{ic|StrictModes}} を一時的に {{ic|no}} に設定してみてください。StrictModes off で認証が成功する場合、おそらくファイルのパーミッションにまだ問題が存在します。
* {{ic|~/.ssh/authorized_keys}} のキーが正しく入力されていることを確認し、1 行のみを使用してください。
* リモートマシンが使用しているタイプの鍵をサポートしていることを確認してください。サーバーが ECDSA 鍵をサポートしていない場合、RSA あるいは DSA 鍵を使ってみてください。
* それでも認証できない場合、sshd をデバッグモードで実行して接続時の出力を確認してください:

 # /usr/bin/sshd -d

* {{ic|id_rsa_server}} など、鍵に別の名前を付けた場合は、{{ic|-i}} オプションで接続する必要があります。

 $ ssh -i id_rsa_server user@server

==参照==
* OpenSSH 鍵管理 [https://www.ibm.com/developerworks/linux/library/l-keyc.html Part 1] [https://www.ibm.com/developerworks/linux/library/l-keyc2/ Part 2] [https://www.ibm.com/developerworks/library/l-keyc3/ Part 3]
* [https://stribika.github.io/2015/01/04/secure-secure-shell.html Secure Secure Shell]