SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-08

SSH鍵管理の基本と安全な設定方法

SSH鍵の仕組みから管理方法まで解説します。デバイスごとのed25519鍵、sshdが求める権限、configのHostブロック、紛失時の鍵の無効化をUbuntu 24.04で確認できます。

SSH 鍵の仕組み

SSH 鍵は 2 つのファイルで構成されます。デバイス上で保持する秘密鍵と、ログインしたいすべてのサーバーにコピーする公開鍵です。接続すると、サーバーは公開鍵を使って、対応する秘密鍵だけが応答できるチャレンジを送信します。秘密鍵がデバイスから外に出ることはないため、ネットワーク上で秘密情報が送信されることはありません。サーバーが侵害されても、攻撃者に盗まれて役立つ情報はありません。これが、鍵がパスワードより安全な理由です。SSH 鍵を適切に管理するには、4 つの習慣が重要です。デバイスごとに 1 つの鍵を使うこと、sshd が要求するファイル権限を設定すること、オプションの入力を省くための ~/.ssh/config ファイルを用意すること、そしてノート PC を紛失した日に鍵を削除できるようにしておくことです。

このガイドでは Ubuntu 24.04 を対象に、それぞれの習慣を説明します。ただし、ここで説明する内容のほとんどは、Linux サーバーと最近の OpenSSH に適用できます。

始める前に、実際のミスを防ぐため、用語を 1 つ確認します。公開鍵は秘密ではありません。チケットに貼り付けたり、メールで送信したり、公開したりしても、公開鍵だけでログインされることはありません。秘密鍵は秘密情報です。そのファイルをコピーし、設定されている場合はパスフレーズも知っている者は、サーバーから見ればあなた本人として扱われます。

鍵を作成する: ed25519 が適切なデフォルトです

サーバーではなく、自分のコンピューターで次を実行します。

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 は鍵の種類を指定します。Ed25519 は現代的なデフォルトです。鍵が短く、高速で、2014 年以降のすべての OpenSSH release でサポートされています。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 つの鍵を作成し、そのデバイスから接続するすべてのサーバーに同じ公開鍵を配置します。鍵はデバイスを識別します。各サーバー上の authorized_keys ファイルには、接続を許可されたデバイスの一覧が記録されます。

このモデルは規模を拡大しやすく、代替方法には予測可能な問題があります。サーバーごとに鍵を作成すると、20 台のサーバーに接続する laptop には 20 個の秘密鍵が必要になり、どの鍵がどのサーバー用か分からなくなります。すべてのデバイスで 1 つの鍵を共有する方法は、さらに危険です。laptop が盗まれたとき、すべてのデバイスが同じ秘密鍵を持っているため、desktop の接続を維持したまま laptop だけを失効させることができません。そのため、すべての場所で鍵を交換し、同時にすべてのデバイスへ再配布する必要があります。

デバイスごとに 1 つの鍵を使用すれば、laptop を紛失しても、各サーバーで 1 行を削除するだけで済みます。authorized_keys から laptop の行を削除すれば、ほかのデバイスは引き続き使用できます。-C で設定したコメントにより、その行を簡単に見つけられます。

このモデルの基本原則は、秘密鍵をデバイス上で作成し、そのデバイスとともに破棄することです。秘密鍵を別のマシンへコピーしてはいけません。また、サーバーへアップロードしてはいけません。新しいデバイスにアクセスを許可する場合は、そのデバイス上で新しい鍵を生成します。

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

簡単な方法は、OpenSSH に付属する ssh-copy-id を使うことです。

ssh-copy-id matt@10.0.0.10

このコマンドは、通常はパスワードなど、現在利用できる認証方法でログインし、サーバー上の ~/.ssh/authorized_keys に公開鍵を追記します。ディレクトリやファイルが存在しない場合は、正しい権限で作成します。新しい SSH セッションを開いて動作を確認します。サーバーからアカウントのパスワードを求められずにログインできるはずです。鍵にパスフレーズを設定している場合は、代わりにローカルの端末からパスフレーズを求められることがあります。このプロンプトはローカルのものであり、サーバーのパスワードではありません。

パスワードログインがすでに無効になっている場合、ssh-copy-id ではログインできないため、行を手動で追加します。まだ利用できるセッション、またはプロバイダーの Web コンソールからログインし、サーバー上で次を実行します。

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

引用符内に、id_ed25519.pub から取得した実際の公開鍵の完全な 1 行を貼り付けます。authorized_keys は 1 行につき 1 つの公開鍵を記録し、これがアクセス許可の全データベースになります。デバイスを追加する場合は行を追記し、デバイスを失効させる場合は行を削除します。新しいサーバーでは、パスワードログインを無効にする直前に、この手順を 新しい VPS の最初の 10 分間 に実施します。

鍵認証を壊す権限設定

これは鍵認証が失敗する最も一般的な原因で、クライアント側では何も表示されないまま失敗します。Ubuntu 24.04 では、sshd はデフォルトで StrictModes yes で動作します。つまり、他のユーザーが編集できる authorized_keys ファイルは使用しません。ファイル、~/.ssh ディレクトリ、またはホームディレクトリを自分以外のユーザーが書き込み可能な場合、sshd は鍵を無視し、クライアントには理由を示さずにパスワード認証へ移行します。（Ubuntu の OpenSSH には、自分専用のプライベートグループだけが書き込み可能で、そのグループに他のユーザーが所属していない場合に限り、例外があります。この例外に依存せず、以下のモードを使用してください。）理由はサーバーのログにのみ記録されます。

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 に複数の鍵が登録されている場合、クライアントは鍵を1つずつ提示します。サーバーは提示された鍵ごとに、認証失敗として試行回数を数えます。十分な数の鍵が読み込まれていると、正しい鍵を試す前に Received disconnect: Too many authentication failures になります。IdentitiesOnly yes を指定すると、クライアントは IdentityFile で指定した鍵だけを提示するため、この障害を防げます。

パスフレーズと ssh-agent

パスフレーズは、ディスク上の秘密鍵ファイルを暗号化します。パスフレーズがなければ、ファイルをコピーした人はすぐに使用できます。パスフレーズがあれば、盗まれたファイルはパスフレーズが推測されるまで使えません。ノートパソコン上の鍵には、これが適切な保護です。ノートパソコンは盗難に遭う可能性があり、そのバックアップが漏えいすることもあるためです。

実際にはパスフレーズの入力が負担にならない理由は ssh-agent です。エージェントは復号済みの鍵をメモリ上に保持します。そのため、ログインセッションごとにパスフレーズを 1 回入力すれば、その後の接続はすぐに確立されます。主要なデスクトップ Linux ディストリビューションと macOS では、すでにエージェントが動作しています。次のコマンドで鍵をエージェントに読み込みます。

ssh-add ~/.ssh/id_ed25519

ssh-add -l は、エージェントが現在保持している鍵を一覧表示します。注意点が 1 つあります。エージェントフォワーディング（ssh -A）を有効にすると、接続中にリモートサーバーがエージェントを使用して、さらに別のサーバーへの認証を行えます。そのため、完全に信頼できるサーバーに対してのみ有効にし、デフォルトでは無効にしてください。

ローテーションと失効: 紛失した laptop に対する訓練

通常の SSH key を失効させるには、その key を持つすべてのサーバーで authorized_keys から該当行を削除するだけです。通知する certificate authority はなく、有効期限を待つ必要もありません。行を削除した時点で、その key による新しいログインは失敗します。

緊急事態ではない今、訓練として実施してください。サーバーを 1 台選び、~/.ssh/authorized_keys を開いて、コメントで key を探します。エディターで行を削除するか、コメントで除外します。

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

次に、失効させた直後のデバイスからログインが失敗することを確認し、別のデバイスからはログインできることを確認します。重要な点が 1 つあります。ログイン時にだけ key が確認されるため、key を削除しても、すでに開いているセッションは終了しません。盗まれたデバイスを失効させる場合は、サーバー上の who も確認し、認識できないセッションを終了してください。

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

避けるべきこと

  • すべてのデバイスで同じ秘密鍵を使わないでください。1 台のデバイスが盗まれた場合に、そのデバイスだけを失効させるには、すべての場所で鍵を交換する必要があります。
  • 秘密鍵を git リポジトリにコミットしないでください。非公開リポジトリでも同様です。自動スキャナーは公開リポジトリを監視しており、push から数分以内に漏えいした鍵を試します。後から公開されたリポジトリでは、履歴全体が漏えいします。
  • サーバーから別のサーバーへ接続できるようにするため、ノートパソコンの秘密鍵をサーバーへアップロードしないでください。サーバー上で別の鍵を生成し、必要な場所でのみその鍵を認証してください。
  • 秘密鍵をチャット、メール、チケットに貼り付けないでください。共有するのは公開鍵である .pub ファイルだけです。

鍵で確実にログインできるようになったら、次の手順としてパスワード認証を無効にしてください。これにより、サーバーに対する継続的なパスワード推測攻撃が成功することはなくなります。そのための drop-in 設定は、VPS の SSH 強化 にあります。

FAQ

SSH key はパスワードを送信せずにどのように機能しますか？

サーバーは ~/.ssh/authorized_keys に公開鍵を保持します。ログイン時にサーバーがチャレンジを送信し、クライアントが秘密鍵でチャレンジに署名すると、サーバーが公開鍵で署名を検証します。秘密鍵がデバイスの外へ出ることはないため、通信中に傍受する対象も、サーバーから盗んで再利用できるものもありません。侵害されたサーバーから漏れるのは公開鍵だけであり、公開鍵を使ってどこかへログインすることはできません。

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

その鍵を 1 台のデバイスだけに保持する限り、複数のサーバーで 1 つの鍵を使用して問題ありません。原則はサーバーごとに 1 つではなく、デバイスごとに 1 つです。ノート PC の公開鍵を、そのノート PC から接続するすべてのサーバーに登録し、デスクトップ PC には別の鍵を使用します。これにより、失効処理が簡単になります。デバイスを紛失した場合は、各サーバーから識別可能な 1 行を削除すればよく、他のデバイスは引き続き使用できます。

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

~/.ssh に 700 を設定し、authorized_keys とすべての秘密鍵に 600 を設定します。これらは使用するアカウントが所有する必要があります。sshd はデフォルトで StrictModes yes で動作するため、自分以外のユーザーが書き込めるファイルやホームディレクトリがあると、鍵を黙って無視します。その場合、唯一の痕跡はサーバーの認証ログまたは journal にある Authentication refused: bad ownership or modes です。

サーバーから SSH key を削除するにはどうすればよいですか？

その鍵が認証に使用されるアカウントの ~/.ssh/authorized_keys から、鍵の行を削除します。正しい行は、鍵の情報の後にあるコメント、つまりラベルで確認できます。その鍵を使った新しいログインは直ちに失敗しますが、すでに開いているセッションは維持されます。そのデバイスが盗まれた場合は、そのデバイスの既存セッションも終了してください。鍵をコピーしたすべてのサーバーで、この操作を繰り返します。

SSH key にパスフレーズは必要ですか？

ノート PC やデスクトップ PC に保存する鍵には必要です。パスフレーズは鍵ファイルを暗号化するため、盗難または漏えいしたコピーだけでは使用できません。また、ssh-agent により、接続のたびではなくセッションごとに 1 回入力するだけで済みます。サーバー上で無人の自動化処理に使用する鍵には、通常パスフレーズを設定しません。入力する人がいないためです。このような鍵は、対象アカウントで実行できる操作を制限して保護します。

#ssh#ssh-keys#security#linux#ubuntu-24-04