4 SSHキー・ペアの使用

SSHでは、認証にキー・ペアを使用できます。キーベースの認証はパスワード認証よりもセキュアです。これは、サーバー構成においてパスワード認証を無効にした場合に総当たり攻撃の回避に役立つためです。

SSHキー・ペアのしくみ

キー認証を使用するには、まず、キー・ペア(公開キーおよび対応する秘密キー)が必要になります。既存のキー・ペアを使用するか新しいキー・ペアを生成することができます。通常、SSHキー・ペアの生成は1回のみであり、変更するのは、そのキー・ペアが漏えいした可能性がある場合や、暗号化基準が異なるシステムにキーを使用してアクセスする場合のみです。すべてのキー・ペアにOpenSSHとの互換性があるわけではなく、必要に応じてキーを変換する必要があります。たとえば、PuTTY sshクライアント・ソフトウェアを使用して生成されたキーは、OpenSSHと直接の互換性がないため、使用前に変換する必要があることがあります。キー形式がわからない場合は、クライアント・ソフトウェアのドキュメントを参照してください。

キー・ペアを取得した後、接続する必要があるサーバーにその公開キーをコピーします。その後そのサーバーに接続するには、対応する秘密キーを指定します。秘密キーは、そのサーバーへのアクセスに使用する単一のクライアントに格納できます。安全のため、秘密キーを複数の場所にコピーすることは回避してください。

キー・ペアを生成するときに、パスワードありでもなしでもそれらを構成できます。パスフレーズがないキー・ペアは、リモート・システムに即座にアクセスできるため、接続するたびにパスフレーズを入力する必要がなく、繰返し操作を省くための自動化に役立ちます。ただし、パスフレーズのないキーを使用すると、セキュリティが低下する可能性があります。かわりに、SSHエージェントを使用してログイン・セッション全体のキー・パスフレーズを記憶できます。

信頼できるシステムから信頼できるシステムに接続するにはSSHエージェント転送の使用を検討してください。または、信頼できないか共有度の高い要塞ホストを介して別のシステムに接続する必要がある場合にはProxyJumpコマンド・オプションの使用を検討してください。

ssh-keygenコマンドの使用によるキー・ペアの生成

ssh-keygenコマンドを使用して公開認証キーと秘密認証キーのペアを生成します。認証キーを使用すると、リモート・システムへの接続のたびにパスワードを入力する必要がなくなります。各ユーザーは、それぞれのキーのペアを生成する必要があります。

ssh-keygenの実行

公開および秘密のSSH2 RSAキーのペアを作成するには:

ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/guest/.ssh/id_rsa): <Enter>
Created directory '/home/guest/.ssh'.
Enter passphrase (empty for no passphrase): password
Enter same passphrase again: password
Your identification has been saved in /home/guest/.ssh/id_rsa.
Your public key has been saved in /home/guest/.ssh/id_rsa.pub.
The key fingerprint is:
5e:d2:66:f4:2c:c5:cc:07:92:97:c9:30:0b:11:90:59 guest@host01
The key's randomart image is:
+--[ RSA 2048]----+
|      .=Eo++.o   |
|      o  ..B=.   |
|          o.= .  |
|         o + .   |
|        S * o    |
|       . = .     |
|        .        |
|       .         |
|                 |
+-----------------+

デフォルトのRSAアルゴリズム以外のアルゴリズムを使用してSSHキー・ペアを作成するには、-tオプションを使用します。指定できる値は、dsa、ecdsa、ed25519およびrsaです。

安全のため、秘密キーに攻撃者からアクセスされる場合に備えて、パスフレーズを指定して秘密キーを暗号化できます。秘密キーを暗号化する場合は、キーを使用するたびにこのパスフレーズを入力する必要があります。パスフレーズを指定しなかった場合は、パスフレーズの入力は要求されません。

詳細は、ssh-keygen(1)マニュアル・ページを参照してください。

キー・ファイルの場所

ssh-keygenは、(秘密キー・ファイルの別のディレクトリを指定しないかぎり)~/.sshに秘密キー・ファイルと公開キー・ファイルを生成します。

ls -l ~/.ssh

total 8
-rw-------. 1 guest guest 1743 Apr 13 12:07 id_rsa
-rw-r--r--. 1 guest guest  397 Apr 13 12:07 id_rsa.pub

パスワード不要のリモート・システム・アクセスの有効化

パスフレーズを必要としないキー・ペアを作成できます。これは、ツールがリモート・システムへのSSHアクセスを必要とする可能性があるが、パスフレーズの入力を求める必要がない繰返し操作を省く環境に役立ちます。

広く使用できるようにするために、秘密キーにパスフレーズを設定してから、SSHエージェントを使用してログイン・セッション全体のキー・パスフレーズを記憶することをお薦めします。詳細は、SSHキー・エージェントの使用によるパスフレーズの記憶を参照してください。

ただし、SSHエージェントの使用は必ずしも実用的というわけではなく、ブート時にロードされる一部のサービスの場合は、パスフレーズを使用しないキーの作成が必要な場合があります。

OpenSSHユーティリティを使用して、接続のたびにパスワードを指定することなくリモート・システムにアクセスするには、次のようにします。

1. ssh-keygenを使用して、公開キーと秘密キーのペアを生成します。たとえば:

   ssh-keygen

   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/user/.ssh/id_rsa): <Enter>
   Created directory '/home/user/.ssh'.
   Enter passphrase (empty for no passphrase): <Enter>
   Enter same passphrase again: <Enter>
   ...

   パスフレーズの入力を要求するプロンプトが表示されるたびに、[Enter]を押します。

2. 公開キーをリモート・サーバーにコピーします。リモート・サーバーへの公開キーのコピーを参照してください。

3. クライアント・システムとサーバー・システムとでユーザー名が異なる場合は、この接続用に~/.ssh/configファイル・エントリを作成します。ホストに関するSSHクライアント構成オプションの設定を参照してください。

4. $HOME/.ssh構成ファイルに対する権限がサーバー側とクライアント側の両方で正しいことを確認します。詳細は、構成権限の確認を参照してください。

5. パスワードを指定せずにリモート・システムにアクセスするには、sshを使用してリモート・システムにログインし、~/.ssh/authorized_keysファイルに接続元のシステム用のキーのみが含まれていることを確認します。次に例を示します。

   ssh remote_user@host

標準的でない方法でキー・ファイルを指定するには、接続時に-Iオプションを使用することで、使用するキー・ファイルを指定します。

ssh -i ~/.ssh/my_private_key remote_user@host

詳細は、ssh-copy-id(1)、ssh-keygen(1)およびssh_config(5)の各マニュアル・ページを参照してください。

リモート・サーバーへの公開キーのコピー

$HOME/.ssh/authorized_keysにあるリモート・サーバー・ファイルに公開キーを追加します。このファイルの内容を設定するには、様々なアプローチを使用できます。ssh-copy-idを実行するか、そのファイルを手動で構成できます。

ssh-copy-idの実行

パスワード認証が有効なシステムでは、ssh-copy-idコマンドを使用して、クライアント・システムからリモート・サーバーに公開キーをコピーできます。このツールでは、$HOME/.sshおよび$HOME/.ssh/authorized_keysの権限も適切に設定されます。

1. ssh-copy-idコマンドを使用して、ローカル~/.ssh/id_rsa.pubファイル内の公開キーをリモート・システム上の~/.ssh/authorized_keysファイルに追加します。次に例を示します。

   ssh-copy-id remote_user@host

2. プロンプトが表示されたら、リモート・システムのパスワードを入力します。

詳細は、ssh-copy-id(1)マニュアル・ページを参照してください。

authorized_keysファイルの手動設定

ssh-copy-idコマンドにアクセスできない場合、またはリモートでパスワードを使用してシステムにアクセスできない場合は、$HOME/.ssh/authorized_keysファイルに手動で入力する必要があります。

1. クライアント・システム上の公開キー・ファイル(通常は$HOME/.ssh/id_rsa.pub)の内容をコピーし、その内容をサーバー・システム上の$HOME/.ssh/authorized_keysに追加します。

2. $HOME/.sshおよび$HOME/.ssh/authorized_keysの権限がサーバー・システム上で正しく設定されていることを確認します。

3. リモート・システムで、次のように~/.ssh/authorized_keysファイルを出力します。

   cat .ssh/authorized_keys

4. 自分のキー・エントリがその出力に含まれているかどうかを確認します。たとえば、エントリが次のように表示されることがあります。

   ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6OabJhWABsZ4F3mcjEPT3sxnXx1OoUcvuCiM6fg5s/ER
   ... FF488hBOk2ebpo38fHPPK1/rsOEKX9Kp9QWH+IfASI8q09xQ== local_user@local_host

認可されたキーの保管場所の一元化

ユーザーにアクセス権をプロビジョニングする必要があるシステムが多数ある場合は、安全性が損なわれたキー・ペアを持つユーザーの公開キーを取り消すことができるように、$HOME/.ssh/authorized_keysファイルのストレージを集中管理するオプションを検討してください。

一般的な方法は、LDAPやアイデンティティ管理(IPA)サービスなどの一元的な場所に格納されているキーにシステム・セキュリティ・サービス・デーモンの使用によってアクセスするように、SSHサーバーを構成することです。これらのサービスに対してユーザー認証を構成するには、『Oracle Linux 8 システム・ユーザーおよび認証の設定』または『Oracle Linux 9 システム・ユーザーおよび認証の設定』を参照してください。

OpenSSHでは、ユーザー認証時にSSSDを使用して公開キーの個別のキャッシュをメンテナンスおよび自動更新するためのツールが提供されます。sss_ssh_authorizedkeysコマンドでは、アイデンティティ管理(IPA)ドメイン内のユーザー・エントリからユーザーの公開キーが取得されます。キーが取得された後、そのキーが、標準の認可済キー形式で$HOME/.ssh/sss_authorized_keysに格納されます。

SSSDを使用してユーザーの公開キーを取得するようにSSHサーバーを構成するには、/etc/ssh/sshd_configを編集して、次のエントリが存在することを確認します:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

サーバー構成を編集した場合は、このサービスを再起動する必要があります。

sudo systemctl restart sshd

SSHがサービスを使用できるようにするには、SSDがすでに構成されて実行中であり、キーが適切に保管されている必要があります。

詳細は、sss_ssh_authorizedkeys(1)マニュアル・ページを参照してください。

known_hostsの使用

リモート・ホストに接続するたびに、リモート・ホスト上のSSHサーバーから公開キーが提供されます。このキーを使用すると、中間者(MITM)攻撃を防ぐために、以降に同じホストに接続していることを確認できます。サーバー側では、この公開キーはHostKeyペアの一部として格納されます。クライアント・システムでは、known_hostsデータベースで、$HOME/.ssh/known_hostsファイルにホストの公開キーが格納されます。

RSAキー・フィンガープリント

リモート・システムに接続したときに、known_hostsデータベースにキーが含まれていない場合は、クライアントによって、キーのフィンガープリントを受け入れるよう求めるプロンプトが表示されます。次に例を示します。

The authenticity of host 'server1.example.com (198.51.100.172)' can't be established.
RSA key fingerprint is SHA256:M/Qa7GZf45KPhXsGgQkCpA5dH8BeY5c6nO87chXBWbk.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

そのフィンガープリントを受け入れると、クライアント・システム上で$HOME/.ssh/known_hostsファイルにその公開キーが格納され、それ以降は、接続しようとしたときに再度プロンプトが表示されることはなくなります。

キーのフィンガープリントの一覧表示

known_hostsデータベースに格納されているキーのフィンガープリントを一覧表示するには、次を実行します。

ssh-keygen -l -f $HOME/.ssh/known_hosts

StrictHostKeyChecking

OpenSSHクライアントでデフォルトでStrictHostKeyCheckingオプションが設定されている場合は、サーバーから返される公開キーが変わると、リモート・サーバーに接続できず、警告が表示されます:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for server1.example.com has changed,
and the key for the corresponding IP address 198.51.100.172
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/user/.ssh/known_hosts:20
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:qMBpuawaY58v7LrcpY2BwtbXHOwP/LXLV8FVZk7tDxY.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/user/.ssh/known_hosts:125
RSA host key for server1.example.com has changed and you have requested strict checking.
Host key verification failed.

ホスト・キーは変更されないため、この警告が表示された場合は、以前に接続したシステムと同じシステムに接続していない可能性があります。ただし、リモート・システムが再インストールされた場合、OpenSSHサーバー・キーが再生成された場合、またはドメイン名エントリやIPアドレスが新しいシステムに再割当てされた場合など、正当な理由によってそのキーが異なることがあります。そのような場合は、known_hostsデータベース内のそのシステムの既存のレコードを削除できます。

既存のキーの削除

リモート・サーバーによって提供された新しいキーを確実に信頼できる場合は、次を実行してknown_hostsデータベースから既存のキーを削除できます。

ssh-keygen -R server1.example.com

Disabling StrictHostKeyChecking

サーバーが常に再インストールされるか置き換えられるテスト環境では、特定のホストに対してStrictHostKeyCheckingを無効にできます。次のように、リモート・システムへの接続時にホスト・キー・チェックを無効にできます。

ssh -o StrictHostKeyChecking=no [e-mail]

厳密なホスト・チェックを常に無効にする必要がある場合は、このオプションをクライアント構成のホスト・エントリに追加することを検討してください。詳細は、ホストに関するSSHクライアント構成オプションの設定を参照してください。

中間者(MITM)攻撃を防ぐために、デフォルトで、厳密なホスト・キー・チェックが有効になっています。そのため、その機能を無効にすることは適切なセキュリティ対策とは考えられず、本番システムではお薦めできません。

SSHキー・ペアの使用に関する関するお薦めの慣例

SSHキー・ペアを管理および使用してネットワーク上のリモート・ホストにセキュアに接続できるように、次のガイドラインに従ってください。

• SSHキー・ペアを生成するときは、強力なパスフレーズを設定します。

  詳細は、ssh-keygenコマンドの使用によるキー・ペアの生成を参照してください。

• ログインするたびにパスフレーズを入力する必要がないように、SSHキー・エージェントを確認します。

  詳細は、SSHキー・エージェントの使用によるパスフレーズの記憶を参照してください。

• パスフレーズを持たず、繰返し操作を省く目的でのみ使用されるSSHキー・ペアへのアクセスを制限します。

  詳細は、特定のコマンドへのSSHキー・アクセスの制限を参照してください。

• 秘密キーを他のユーザーと共有しないでください。システム管理者がネットワーク・リソースへのアクセスを制御できるように、チームの各メンバーに、そのメンバー固有のSSHキー・ペアを持つ必要があります。

• 秘密キーをコピーしないでください。また、SSHエージェントを他のマシン、リモート・サーバーまたはクラウド・インスタンスに転送しないでください。

  詳細は、リモート・サーバーへの公開キーのコピーを参照してください。

• 要塞またはジャンプ・ホストに秘密キーのコピーを格納しないでください。

  詳細は、要塞ホストを介したアクセスのためのProxyJumpの使用を参照してください。