SSH鍵ジェネレーター

RSA 2048 ビットは現在のセキュリティ基準を満たしており、少なくとも 2030 年まで NIST で承認されています。RSA 4096 ビットは、長年使用される予定の鍵に対してより大きなセキュリティマージンを提供しますが、ハンドシェイク操作が大幅に遅くなります（2048 ビットの約 4 倍遅い）。ほとんどのユースケース（サーバーへのアクセス、GitHub/GitLab、CI/CD パイプライン）では、2048 ビットで十分です。高セキュリティ環境で使用される鍵や、10 年以上使用されることが予想される鍵には 4096 ビットを使用してください。速度とセキュリティの最適な組み合わせについては、代わりに Ed25519 を使用してください。

パスフレーズは秘密鍵ファイルを暗号化するもので、たとえ誰かがファイルを入手しても、パスフレーズなしでは使用できないようにします。キーを使用する際、SSH クライアントはパスフレーズの入力を求めます（ssh-agent を使用すれば、復号されたキーをキャッシュできるため、繰り返し入力を求められません）。ユーザー向けのキー（ノートパソコンからサーバーへの接続など）には、パスフレーズを使用してください。マシンを紛失したり盗まれたりした場合に重要な保護を提供します。人間の介入なしに実行される自動化された CI/CD デプロイ用の鍵の場合、パスフレーズで保護された鍵は実用的ではないため、ファイル権限やシークレット管理システムなどの他の手段で鍵ファイルを保護する必要があります。

公開鍵の内容（「ssh-rsa」または「ssh-ed25519」で始まる部分）をコピーし、サーバー上の ~/.ssh/authorized_keys ファイルに追記します。1 行に 1 つの公開鍵を記述してください。ディレクトリが存在しない場合は、mkdir -p ~/.ssh && chmod 700 ~/.ssh を実行します。正しい権限を設定するには、chmod 600 ~/.ssh/authorized_keys を実行します。ローカルマシンから最も速い方法は、ssh-copy-id user@hostname（初回セットアップのみパスワードを使用）です。その後、SSH は自動的にあなたのキーを使用します。秘密鍵は常にローカルマシンのみに保存され、どこにもアップロードされることはありません。

コメントは、公開鍵のデータの後に埋め込まれたラベルです（例：ssh-ed25519 AAAA... user@laptop）。認証には影響を与えず、純粋に説明用です。サーバー上の authorized_keys を確認する際に、キーの起源を特定するために使用します（誰が作成したか、どのマシンからか、何の目的かなど）。一般的な形式には、user@hostname（デフォルト）、メールアドレス、または 「ci-deploy-prod-2026」 のような説明的なラベルがあります。authorized_keys に複数のキーがある場合、意味のあるコメントは、問題が発生した際にどのキーを無効にするかを知るための手段となります。

フィンガープリントは公開鍵の SHA-256 ハッシュで、Base64 形式（例：SHA256:abc123...）で表示されます。これは特定のキーを識別および検証するための簡潔な方法です。SSH でサーバーに初めて接続する際、サーバーは自身のホストキー フィンガープリントを表示します。正しいサーバーに接続しているかを確認するためにこれを確認します。GitHub、GitLab、その他のサービスに公開鍵をアップロードすると、それらのサービスがフィンガープリントを表示します。フィンガープリントがこのツールに表示されたものと一致していれば、キーは正しくアップロードされました。また、自分のマシンで ssh-keygen -l -f ~/.ssh/id_ed25519 を実行して、ローカルでフィンガープリントを確認することもできます。

はい。すべての鍵生成には Web Crypto API が使用されています。これはブラウザのネイティブ API で、オペレーティングシステムのエントロピーソースに裏打ちされた暗号的に安全な操作を提供します。乱数生成には、安全でない Math.random() ではなく crypto.getRandomValues() を使用しています。生成される鍵は、コマンドラインの ssh-keygen で生成されるものと同等のセキュリティを持っています。何もサーバーに送信されません。キーペアはあなたのブラウザセッション内のみに存在します。

既存の authorized_keys をすぐに置き換えるのではなく、新しい公開鍵を追加のエントリとして追記してください。その上で、現在のセッションを閉じずに、別の SSH セッションを開いて新しいキーをテストします。新しいキーが動作することを確認してから、古いキーを削除したりパスワードポリシーを変更したりしてください。もし自分自身を締め出してしまった場合は、サーバーのコンソールへのアクセス（クラウドプロバイダーでは「緊急用コンソール」や「レスキューモード」と呼ばれます）が必要になり、手動で authorized_keys を編集する必要があります。