SSH keyの管理方法と正しい使い方

SSH key の仕組み

SSH key は 2 つのファイルのペアです。デバイス内に保持する private key と、ログイン先の各 server にコピーする public key です。接続時、server は public key を使用して challenge を送信します。この challenge には、対応する private key でしか回答できません。private key がデバイス外に出ることはないため、ネットワーク上に機密情報は流れません。また、server が侵害されても、盗まれるべき有用な情報はありません。これが、password よりも key が優れている理由です。SSH key の適切な管理には、4 つの習慣があります。デバイスごとに 1 つの key を作成すること、sshd が要求する file permissions を守ること、オプション入力を省くための ~/.ssh/config file の使用、そして laptop の紛失時に即座に key を削除する方法を知っておくことです。

このガイドでは Ubuntu 24.04 で各習慣を説明します。ただし、内容はほとんどの Linux server および最新の OpenSSH に適用可能です。

誤操作を防ぐため、用語の定義を説明します。public key は機密情報ではありません。チケットへの貼り付け、メール送信、公開が可能です。これだけでログインされることはありません。機密情報は private key です。このファイルをコピーし、かつ passphrase を知っている者は、server から見れば本人とみなされます。

キーの作成: ed25519 が推奨されるデフォルトです

サーバーではなく、自身のコンピュータで以下を実行してください:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 でキーの種類を選択します。Ed25519 は現代的なデフォルトです。このキーは短く、高速で、2014年以降のすべての OpenSSH リリースでサポートされています。ed25519 を解釈できない古いデバイスと通信する場合のみ、ssh-keygen -t rsa -b 4096 を使用してください。-C "laptop" はコメントを設定します。コメントは暗号学的な機能を持たず、2年後にサーバーの authorized_keys ファイル内でこのキーを識別するために使用されます。そのため、キーを保存するデバイスの名前を入力してください。

ssh-keygen はキーの保存先を尋ねます。デフォルトの ~/.ssh/id_ed25519 を選択してください。次にパスフレーズが求められます。パスフレーズを設定してください。パスフレーズを使用しても、日常的な作業に支障がない理由は、以下のセクションで説明します。最終的に2つのファイルが生成されます。~/.ssh/id_ed25519 は秘密鍵、~/.ssh/id_ed25519.pub は公開鍵です。公開鍵の内容を確認してください:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

公開鍵は1行で構成されます。キーの種類、キー本体、およびコメントが含まれます。この1行がサーバーに保存される内容です。

サーバーごとではなく、デバイスごとに1つの鍵を使用する

誰もが最初に抱く疑問：サーバーごとに新しい鍵が必要ですか？ いいえ。使用するデバイスごとに1つの鍵を作成してください。そして、そのデバイスがアクセスする必要のあるすべてのサーバーに、その公開鍵を登録します。鍵はデバイスを識別するためのものです。各サーバーにある authorized_keys ファイルは、アクセスを許可するデバイスのリストです。

このモデルは拡張性に優れています。他の手法は予測可能な問題を引き起こします。サーバーごとに鍵を作成する場合、20台のサーバーに接続するノートPCには20個の秘密鍵が保存されることになり、どの鍵がどれであるか管理できなくなります。すべてのデバイスで1つの鍵を共有するのはさらに危険です。ノートPCを紛失した場合、デスクトップPCも同じ秘密鍵を使用しているため、ノートPCのアクセス権だけを無効化できません。すべての場所で鍵を更新し、すべてのデバイスに再配布する必要があります。

デバイスごとに鍵を管理していれば、ノートPCを紛失しても、各サーバーで1行を削除するだけで済みます。authorized_keys から該当するノートPCの行を削除すれば、他のデバイスは引き続き動作します。-C で設定したコメントにより、その行を簡単に見つけることができます。

このモデルの原則：秘密鍵はデバイス上で作成され、そのデバイスと共に破棄されます。秘密鍵を別のマシンにコピーしたり、サーバーにアップロードしたりしないでください。新しいデバイスにアクセス権が必要な場合は、そのデバイス上で新しい鍵を生成してください。

サーバーに公開鍵を配置する

最も簡単な方法は、OpenSSHに付属している ssh-copy-id を使用することです。

ssh-copy-id matt@10.0.0.10

このコマンドは、現在有効な認証方法（通常はパスワード）でログインします。サーバー上の ~/.ssh/authorized_keys に公開鍵を追記し、ディレクトリやファイルが存在しない場合は適切な権限で作成します。新しいSSHセッションを開いてテストしてください。サーバーはアカウントのパスワードを求めずにログインを許可するはずです。鍵にパスフレーズを設定している場合、ローカルマシンでその入力を求められることがあります。これはローカルでの処理であり、サーバーのパスワードではありません。

パスワード認証が既に無効化されている場合、ssh-copy-id はログインできないため、手動で行を追加する必要があります。まだ利用可能なセッション、またはプロバイダーのウェブコンソールからログインし、サーバー上で以下のコマンドを実行してください。

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

引用符の中に、id_ed25519.pub から取得した公開鍵の全行を貼り付けてください。authorized_keys は1行につき1つの公開鍵を保持する形式であり、これがアクセスリストのすべてです。デバイスを追加するには行を追記し、デバイスの権限を削除するには行を削除します。新規サーバーの場合、この手順は 新しいVPSでの最初の10分間 の、パスワード認証を無効にする直前の工程に含まれます。

鍵ログインを失敗させる権限設定

これは鍵ログインが失敗する最も一般的な原因です。クライアント側にはエラーが表示されず、静かに失敗します。Ubuntu 24.04では、sshdはデフォルトでStrictModes yesで動作します。これは、他のユーザーが編集可能なauthorized_keysファイルの使用を拒否することを意味します。ファイル、~/.sshディレクトリ、またはホームディレクトリが、あなた以外のユーザーによって書き込み可能である場合、sshdは鍵を無視します。その結果、クライアントには理由が表示されず、パスワード入力へとフォールバックされます。（UbuntuのOpenSSHには、例外的なケースが1つだけあります。それは、あなた自身のプライベートグループのみが書き込み可能で、他の誰もそのグループに属していないファイルグループです。これに頼らず、以下のモードを維持してください。）原因はサーバーのログにのみ表示されます。

sudo grep 'Authentication refused' /var/log/auth.log

rsyslogが含まれていない最小構成のイメージにはauth.logはありません。その場合、同じ行はjournalに記録されます：sudo journalctl -u ssh | grep 'Authentication refused'。

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

修正するには、サーバー上で該当するユーザーとして、2つの権限変更と所有権の確認を実行します。

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

覚えておくべきルール：.sshディレクトリには700を、その中のすべてのファイルには600を設定してください。クライアント側でもチェックが行われるため、自分のコンピュータでも同じ設定が必要です。他のユーザーが読み取り可能な秘密鍵を使用すると、sshが鍵を完全に拒否します。この場合、エラーが明示的に表示されます。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519で解決します。

~/.ssh/config: オプションの入力を省略する

ローカルコンピュータ上の ~/.ssh/config ファイルを使用すると、各サーバーに短い名前を割り当て、繰り返し入力するオプションを保存できます。600 権限でファイルを作成し、サーバーごとに Host ブロックを追加してください。

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

これにより、ssh web1 が ssh -p 22 matt@10.0.0.10 の代わりとして機能します。すべてのクライアントがこのファイルを読み込むため、同じ短い名前が scp、rsync、git でも使用可能です。HostName は実際の接続先アドレスであり、User はユーザー名の入力を省略し、IdentityFile は使用する鍵を指定します。

IdentitiesOnly yes については、混乱を招くエラーを解決するために説明が必要です。agent に複数の鍵が登録されている場合、クライアントはそれらを順番に提示します。サーバーは、提示されるたびに失敗した試行としてカウントします。多くの鍵がロードされていると、正しい鍵が試行される前に Received disconnect: Too many authentication failures が発生します。IdentitiesOnly yes を使用すると、クライアントは IdentityFile で指定された鍵のみを提示するため、このエラーを防げます。

Passphrases and ssh-agent

Passphraseは、ディスク上のprivate keyファイルを暗号化します。Passphraseがない場合、ファイルがコピーされると即座に悪用されます。Passphraseがあれば、パスワードが推測されるまで盗まれたファイルは使用できません。ノートPCのキーには、この保護が不可欠です。ノートPCの紛失や、バックアップからの情報漏洩のリスクがあるためです。

実用上のコストがssh-agentで済む理由は、agentの仕組みにあります。agentは復号されたkeyをメモリ内に保持します。そのため、ログインセッション中に一度パスphraseを入力するだけで、その後の接続はすべて即座に行えます。ほとんどのデスクトップLinuxディストリビューションやmacOSでは、すでにagentが動作しています。以下のコマンドでkeyをロードしてください。

ssh-add ~/.ssh/id_ed25519

ssh-add -lは、agentが保持しているkeyの一覧を表示します。注意点として、agent forwarding (ssh -A) を有効にすると、接続中にリモートサーバーがあなたのagentを使用して認証を継続できます。そのため、完全に信頼できるサーバーに対してのみ有効にし、デフォルトではオフにしてください。

ローテーションと失効：紛失したノートPCへの対処手順

通常のSSH keyの失効は、そのkeyが登録されているすべてのサーバーの authorized_keys から該当する行を削除するだけです。通知すべき認証局（CA）も、待機すべき有効期限もありません。行が削除された瞬間に、そのkeyによる新しいログインは失敗します。

緊急事態になる前に、この手順を試してください。サーバーを1台選び、~/.ssh/authorized_keys を開き、コメントを頼りにkeyを見つけます。エディタでその行を削除するか、コメントでフィルタリングしてください。

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

次に、失効させたデバイスからはログインできないこと、別のデバイスからは引き続きログインできることを確認してください。注意点として、keyのチェックはログイン時にのみ行われるため、keyを削除しても既に確立されているセッションは終了しません。盗難に遭ったデバイスの失効を行う場合は、サーバーの who も確認し、身に覚えのないセッションをすべて終了させてください。

ローテーションは、手順の順序が異なるだけで同じ操作です。デバイスで新しいkeyを生成し、ssh-copy-id でインストールします。新しいkeyでログインできることを確認した後、古い行を削除します。デバイスの所有者が変わる際、keyが漏洩した可能性がある場合、またはチームメンバーが離脱する場合に行ってください。2台のサーバーに対して手動で行うのは問題ありませんが、20台以上の場合は自動化が必要です。複数のLinuxサーバーの管理 では、一括して authorized_keys の状態を適用する方法を解説しています。

やってはいけないこと

• すべてのデバイスで一つの private key を共有しないでください。デバイスが盗まれた場合、そのキーをすべて置き換えない限り、特定のデバイスのみを無効化することができなくなります。

• git repository に private key をコミットしないでください。たとえ private なリポジトリであっても禁止です。公開リポジトリは自動スキャナーによって監視されており、push から数分以内に漏洩したキーが検知されます。また、後からリポジトリを公開設定に変更した場合、過去の履歴すべてからキーが漏洩します。

• あるサーバーから別のサーバーへアクセスするために、ノートPCの private key をサーバーにアップロードしないでください。サーバー上で別途 key を生成し、必要な場所にのみその key を登録してください。

• チャット、メール、または ticket に private key を貼り付けないでください。共有してよいのは public key である .pub ファイルのみです。

key によるログインが安定したら、次のステップとして password authentication を無効にしてください。これにより、サーバーに対する継続的な総当たり攻撃を防ぐことができます。設定の詳細は SSH hardening on a VPS を参照してください。

FAQ

パスワードを送信せずにSSH keyが機能する仕組みは？

サーバーは ~/.ssh/authorized_keys にあなたの public key を保持します。ログイン時、サーバーは challenge を送信します。クライアントは private key でその challenge に署名し、サーバーは public key で署名を検証します。private key がデバイスから送信されることはないため、通信中に傍受されることはありません。また、サーバーから盗まれても再利用できる情報はありません。サーバーが侵害されても public key が漏洩するだけであり、それを使って他の場所へログインすることはできません。

すべてのサーバーで同じSSH keyを使用すべきですか？

その key が単一のデバイス内に保持されている限り、複数のサーバーで同じ key を使用しても問題ありません。原則は「1サーバーにつき1つのkey」ではなく「1デバイスにつき1つのkey」です。例えば、ノートPCの public key は、そのPCが必要とするすべてのサーバーに登録し、デスクトップPCには別の key を使用します。これにより、デバイスを紛失した際の失効作業が簡単になります。各サーバーから該当する行を削除するだけで済み、他のデバイスでの作業は継続できます。

.ssh ディレクトリと authorized_keys にはどのような権限を設定すべきですか？

~/.ssh には 700 を、authorized_keys およびすべての private key には 600 を設定してください。これらは使用するアカウントが所有している必要があります。sshd はデフォルトで StrictModes yes で動作します。そのため、あなた以外のユーザーが書き込み可能なファイルや home directory がある場合、sshd はその key を黙って無視します。その際、サーバーの auth log または journal には Authentication refused: bad ownership or modes が記録されます。

サーバーからSSH keyを削除する方法は？

対象のアカウントの ~/.ssh/authorized_keys から、該当する key の行を削除してください。key の後ろにあるコメント（ラベル）を頼りに、正しい行を見つけてください。削除後、その key を使った新しいログインは即座に失敗しますが、既に確立されているセッションは維持されます。デバイスを紛失した場合は、実行中のセッションも終了させてください。その key をコピーしたすべてのサーバーでこの操作を繰り返してください。

SSH keyに passphraseを設定する必要はありますか？

ノートPCやデスクトップで使用する key の場合は、必要です。passphrase は key ファイルを暗号化するため、ファイルが盗まれたり漏洩したりしても、それ単体では使用できません。また、ssh-agent を使用すれば、接続のたびではなく、セッションごとに一度だけ入力すれば済みます。サーバー上の自動化プロセス（unattended automation）で使用する key には、通常 passphrase は設定しません。入力する人間が存在しないためです。これらの key を使用するアカウントについては、実行できる操作を制限することで保護してください。