SSHキーの解説

SSHキー認証は、パスワードなしでサーバーにログインする方法です。サーバーが検証できる秘密を入力する代わりに、あなたのコンピュータはサーバーが送るチャレンジに署名することで秘密鍵を持っていることを証明し、サーバーはすでに保管している公開鍵で署名を検証します。秘密鍵がネットワークを横切ることは決してないため、傍受されるものも、フィッシングで釣られるものも、推測されるものもありません。この記事では、キーペアの2つの半分の仕組み、2026年に選ぶべきキーの種類、フィンガープリントが初回接続時に中間者を止める方法、authorized_keysとknown_hostsを清潔に保つ方法、そしてキーが漏洩したときに具体的に何をすべきかを説明します。ブラウザでキーを生成・検査・変換するにはSSHキー スイートを、まだ使っているパスワードの確認にはパスワード漏洩チェックを使ってください。

SSHキー認証とは何か

すべてのログインは、サーバーが投げかける問いです。「あなたは本当にあなたが主張する人物ですか?」パスワードは、その秘密そのものを渡すことで答えます。これがこの仕組み全体の弱点です。秘密は移動し、盗み聞きされ、再生され、破られるまで何度も推測されます。SSHキー認証は答えを変えます。秘密を送る代わりに、あなたのコンピュータはあなたのマシンを決して離れない秘密鍵でサーバーからのランダムなチャレンジに署名し、サーバーはauthorized_keysファイルに保存された公開鍵で署名を検証します。チャレンジがランダムであるため、証明は毎回新鮮です。秘密が通信路上に現れることは決してないため、盗聴者は再利用できるものを何も学べません。そして、そもそもパスワードが関与しないため、推測すべきパスワードもありません。

この考えは現代のインターネットよりも古く、公開鍵暗号は1970年代にさかのぼります。しかしSSHはそれをサーバーに到達する日常的な方法にし、プロトコルはそれ以来それを担ってきました。ssh user@serverを実行すると、クライアントとサーバーはセッションに合意し、サーバーはあなたのアカウントに結びついたチャレンジを提示し、あなたのSSHエージェントは秘密鍵でそれに署名します。通常はパスフレーズで鍵を一度アンロックした後です。署名が検証されれば、ログインできます。この交換は、サーバーも知っている共有秘密には何も依存しません。そのため、サーバーが侵害されてもあなたの認証情報は漏れません。サーバーが持つのは公開鍵だけで、公開鍵はログインには無用だからです。この非対称性、つまりサーバーは検証できてもなりすますことはできないという点が、鍵の安全保障の論拠のすべてであり、秘密の半分の管理を失うことが唯一重要な失敗である理由でもあります。

公開鍵と秘密鍵

キーペアは正反対のルールを持つ2つの半分であり、ほとんどのSSHの間違いは、それらを同じものとして扱うことから生じます。公開鍵はあらゆるところにコピーするためのものです。使うすべてのサーバーのauthorized_keys、Gitホスティングアカウント、SSHキーを受け入れるあらゆるサービスに貼り付けてください。公開リポジトリに公開したり、スライドに印刷したり、管理者にメールで送ったりできます。なぜなら、それで誰かにできるのは署名を検証することだけだからです。あなたの公開鍵を知っても、攻撃者はログインするための何も得られません。あなたの住所を知っても、誰もあなたの玄関の鍵を手に入れられないのと同じです。公開の半分は錠前であり、鍵ではありません。そして錠前は見られるためにあるのです。

秘密鍵は鍵そのものであり、そのルールは正反対です。あなたのマシンを決して離れず、あなただけが読むことができ、チャット、チケット、メール、フォーラムの投稿、共有ドキュメントに決して貼り付けてはいけません。安全かどうか尋ねるためでもだめです。これを持つ者は、対応する公開鍵を信頼するすべてのサーバーにあなたとしてログインできます。パスワードの入力も、設定していない限り第二要素も、途中にありません。ディスク上では~/.sshに住み、ファイルパーミッション、つまりchmod 600(所有者のみ読み書き可)によって保護され、理想的にはパスフレーズによっても保護されます。パスフレーズはファイルを暗号化するため、盗まれたコピーも、それをアンロックする言葉がなければ無用です。パスフレーズは鍵の一部ではありません。鍵が入っている箱の南京錠です。箱を失えば、南京錠が泥棒とあなたのサーバーの間にある唯一のものになります。そのため、パスフレーズのない秘密鍵は、あなたが完全に管理するマシンを決して離れてはいけません。

Ed25519とECDSA、RSA:2026年に選ぶべきもの

2026年のデフォルトの答えはEd25519であり、このサイトが生成するデフォルトでもあります。Ed25519は256ビットの楕円曲線鍵です。1秒の何分の1かで生成され、署名が速く、公開鍵は短い1行に収まります。2014年からOpenSSHに、すべての現在のサーバーとクライアントにサポートされており、その安全性は、不審な定数のない、公開の場で設計された曲線に依拠しています。環境の何かが手を縛らない限り、新しい鍵にほかのものを選ぶ実用的な理由はありません。この記事から1つの推奨だけを持ち帰るなら、これです。Ed25519を生成し、パスフレーズを設定し、先に進んでください。

ほかの種類は例外のために存在します。NISTのP-256曲線またはP-384曲線上のECDSAは、ポリシーがNIST曲線を要求する場合の正しい選択です。規制された環境や古いハードウェアトークンの中にはそれを指定するものがあり、ブラウザやデバイスがEd25519を生成できない場合の確かな代替でもあります。RSAは依然として汎用の代替です。RSA 2048が使う価値のある下限であり、RSA 3072または4096は、相手側が楕円曲線をまったく使えない場合の選択です。今日では、これは主に非常に古いシステムといくつかの組み込みデバイスを意味します。RSA 2048未満のもの、つまりRSA 1024、DSA、ssh-dssはすべて旧式であり、廃止すべきです。SSHキー スイートがそれらを弱い鍵としてフラグを付けるのは、まさにそのためです。ただし、鍵のサイズがすべてではありません。もう所有していないノートパソコンにコピーされた4096ビットのRSA鍵は、きちんと保管された256ビットのEd25519鍵よりも悪いものです。SSHキーの失敗モードは、ほとんど決して数学ではないからです。ファイルなのです。

フィンガープリントと初回接続

サーバーに初めて接続すると、SSHはランダムな文字列のように見えるものを表示し、それを信頼するかどうか尋ねます。256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ。この文字列はサーバーのホスト鍵のフィンガープリント、つまりサーバーの公開鍵のハッシュであり、あなたと中間者の間にある唯一のものです。フィンガープリントが管理者が公開したもの、あるいは別のチャネルで確認したものと一致すれば、応答しているマシンは確かにあなたが到達しようとしたサーバーです。一致しなければ、止まってください。誰かが接続を傍受しているか、サーバーが新しい鍵で再構築された可能性があり、いずれにせよ、安全な行動はyesと入力する前に確認することです。このプロンプトは、SSHが最も重要な仕事をしているときであり、トラブルに巻き込まれるのは、読まずにyesと入力する訓練をしてしまった人々です。

フィンガープリントは、接続する前にssh-keygen -lfで確認できます。これは鍵ごとに1行を出力します。ビット数、フィンガープリント、コメント、角括弧内のキーの種類です。たとえば256 SHA256:… [email protected] (ED25519)のようになります。SSHキー スイートはフィンガープリントをまったく同じ形式で出力するため、ブラウザで見る値をサーバーが表示するものと1文字ずつ比較できます。ホスト鍵を一度受け入れると、SSHはそれを~/.ssh/known_hostsに保存し、変わったときには大声で警告し、接続を拒否します。この警告は、フラグで回避すべき煩わしさではありません。鳴っている警報なのです。唯一の日常的な例外は、正当に再構築されたサーバーです。その場合、管理者は新しいフィンガープリントを事前に公開しているはずであり、再接続する前にssh-keygen -R hostnameで古いエントリを削除します。

authorized_keysの衛生管理とknown_hosts

サーバーのauthorized_keysファイルの各行は1つの扉であり、扉は、それを必要としていた人が去ったずっと後も開いたままです。請負業者のノートパソコン、継続的インテグレーションのジョブ、すでに消去されたマシンで生成された鍵、2年前にチームを変わった同僚。これらはそれぞれが今も機能する行であり、それぞれがあなたがもう見守っていない認証情報です。監査はシンプルで、数か月に一度行う価値があります。ファイルをコピーし、SSHキー スイートの「検査」タブに貼り付け、返ってくるものを見てください。重複、つまり同じ公開鍵が2回あることは、誰かが確認する代わりに鍵をもう一度貼り付けたことを意味し、1行にまとめるべきです。弱いエントリ、つまり2048未満のRSA、DSA、ssh-dssは削除して交換すべきです。そして、コメントに挙げられた人物、マシン、目的がもうわからない行は、持ち主が名乗り出るまで閉じるべき扉として扱ってください。

known_hostsも、反対側から同じ注意に値します。接続したすべてのサーバーのホスト鍵を記録し、SSHはそれと照らして新しい接続を毎回確認します。一部のエントリはハッシュ化されています。|1|の後にbase64が続くもので、ホスト名を隠します。これは、紛失したり検査されたりする可能性のあるノートパソコン向けのプライバシー機能です。SSHキー スイートは、それらのエントリを読めるふりをするのではなく、ハッシュ化済みとして報告します。ハッシュ化されたエントリは公開されたフィンガープリントと照合して検証できず、すでに受け入れられたものとして信頼するしかないからです。ファイルそのものも証拠です。もう使っていないサーバーでいっぱいのknown_hostsは、あなたの認証情報がどこに行ったかの地図であり、整理するのに何もかかりません。この2つのファイルを合わせると、あなたのSSHの信頼が両方向に及ぶ完全な記録になります。誰があなたとしてログインできるか、そしてどのマシンをそれ自身として信頼するか。どちらも、誰も見なければ静かに腐っていきます。

キーが漏洩したとき — そしてパスフレーズの注意点

漏洩した鍵は、まず調査して後で行動する謎ではありません。交換すべき鍵であり、操作の順序は短いものです。新しいキーペアを生成してください。古い公開鍵をすべてのサーバーとすべてのサービスのauthorized_keysから削除してください。あなたのサーバー、Gitホスティング、デプロイパイプライン、鍵がインストールされたあらゆる場所です。次に、古い鍵が何に到達できたかを確認し、場違いなものがないか探してください。あなたが追加しなかったauthorized_keysの新しい行、あなたが働いていなかった時間帯のログイン、見慣れないプロセスです。何か見つかれば、それを驚きではなく侵害として扱い、そこから調査してください。してはいけないのは、古い秘密鍵を自分のノートパソコンから削除して仕事が終わったと考えることです。自分のコピーを削除しても、漏洩したコピーには何の効果もなく、authorized_keysにまだ残っている公開鍵は今も機能する扉です。

パスフレーズはこのチェックリストを変えませんが、実行する緊急度を変えます。ファイルとして漏洩したパスフレーズ保護付きの鍵は依然として問題です。攻撃者はパスフレーズをオフラインで、機械の速度で推測しようとできます。しかし、強いパスフレーズは、推測が成功する前にローテーションするための時間を買ってくれます。暗号化されていない鍵は時間をまったく買ってくれません。だからこそ、このサイトは生成器が何を生み出すかについて率直です。バージョン1は暗号化されていない鍵を生成し、パスフレーズの選択肢はありません。暗号化された秘密鍵のためのOpenSSHのbcrypt KDFはバージョン2の範囲だからです。ここで鍵を生成したら、chmod 600でファイルを保護し、自分のマシンでssh-keygen -pを使ってパスフレーズを追加してください。10秒で済み、ファイルをその場で変換でき、この記事全体で最も価値の高い習慣です。鍵を生成し、パスフレーズを設定し、公開の半分だけをインストールし、年に2回ファイルを監査し、信頼する前にすべてのフィンガープリントを確認してください。それが規律のすべてであり、索引カードに収まります。

出典と関連資料

よくある質問

2026年にどのSSHキーの種類を使うべきですか?

ほぼすべての場合にEd25519を使ってください。256ビットで高速、小型であり、すべての現在のサーバーとクライアントが対応しています。ポリシーがNIST曲線を要求する場合にのみECDSA P-256を、相手側が楕円曲線を使えない場合にのみRSA 3072または4096を使ってください。RSA 2048未満のものはすべて廃止してください。

正しいサーバーに接続していることをどうやって知るのですか?

初回接続時にSSHが表示するホスト鍵のフィンガープリントを、管理者が公開したフィンガープリントと比較してください。ssh-keygen -lfまたはSSHキー スイートを使ってください。どちらも同じ形式でフィンガープリントを出力します。一致すれば受け入れてください。SSHはそれをknown_hostsに保存し、変わったときには警告します。一致しなければ、yesと入力する前に止まって確認してください。

秘密鍵が漏洩しました。まず何をすべきですか?

新しいキーペアを生成し、古い公開鍵をすべてのサーバーとサービスのauthorized_keysから削除してください。Gitホスティングとデプロイパイプラインも含みます。自分の秘密鍵のコピーを削除するだけでは不十分です。公開鍵が削除されるまで、漏洩したコピーは機能し続けるからです。次に、古い鍵が何に到達できたかを確認し、使用の痕跡がないか調べてください。