SSH 鍵

機能

• 公開鍵を解析：種類・ビット数・コメント・行頭の `authorized_keys` オプション
• ⚠️ SHA-256 と MD5 の両方のフィンガープリント。`ssh-keygen -lf` の出力と 1 文字まで一致
• ⚠️ MD5 が旧形式であることを明記 —— 一致しないときはまず形式を確認
• ⚠️ RSA のビット数は blob 内の modulus から数え、base64 の長さから推定しません
• オプション付きの行（`command="echo a b",no-pty ssh-ed25519 …`）を空白で分解しません
• Ed25519 または RSA 2048 / 3072 / 4096 を生成
• ⚠️ 生成される秘密鍵は PKCS#8 PEM。OpenSSH 形式へ変換するコマンドも表示（bcrypt_pbkdf はブラウザーにありません）
• ⚠️ 「鍵はブラウザーのメモリにしかなく、閉じれば失われる。今すぐコピー」と明示
• 生成後に公開鍵を読み直して自己検証 —— 「生成したもの」と「読み取ったもの」が一致します
• すべてブラウザー内で完結し、鍵は送信も保存もされません

使い方

1. 解析：公開鍵の 1 行を貼り付けます（`~/.ssh/id_ed25519.pub` からまるごとコピー）
2. 生成：「行う処理」を生成に切り替え、種類とコメントを指定します
3. 解析では、フィンガープリントの行をサーバー上の `ssh-keygen -lf` と見比べます

よくある質問

フィンガープリントが 2 つあるのはなぜですか？どちらを見るべきですか？

同じものの 2 通りの表記だからです：どちらも base64 を解いたバイト列をハッシュしたもので、片方が SHA-256、もう片方が MD5 です。見るべきは SHA-256 —— `ssh-keygen` は OpenSSH 6.8（2014 年）以降これを既定にしており、MD5 はもはやセキュリティ上の判断に使うべきではありません。MD5 を出しているのは、古いサーバーや資料、管理画面がいまだに印字しており、形式の違いが「鍵が違う」と誤解されるためです。一致しないときは接頭辞（`SHA256:` か `MD5:`）を確認してください。

生成した秘密鍵をそのまま ssh で使えないのはなぜですか？

`ssh-keygen` が書く新しい秘密鍵（`-----BEGIN OPENSSH PRIVATE KEY-----`）は、パスフレーズから暗号鍵を導くのに bcrypt_pbkdf を使っており、その KDF はブラウザーの暗号 API にない —— Web ページでは作れないからです。そこでここでは標準の PKCS#8 PEM を出力し、`ssh-keygen -p -m pem` での変換コマンドを添えています。`.ssh/id_ed25519` のようなファイルが作れるふりをすると、コピーすれば使えると誤解され、ssh は形式エラーを出すだけです。

authorized_keys の鍵の前にある文字列は何ですか？

その鍵に対する制限で、貼り付けるときに落としてはいけません。よくあるものは：`command="..."` はその 1 コマンドだけの実行を許す（デプロイ鍵でよく使われます）、`from="10.0.0.*"` は接続元の制限、`no-pty` は端末の割り当てを禁止、`no-port-forwarding` は転送を禁止。これらを落とすことは、その鍵の権限を無制限に広げること —— まさにそれが防ぐために付けられたものです。

Ed25519 と RSA のどちらを選ぶべきですか？

制約がなければ Ed25519 です。短く（公開鍵 68 文字、RSA 2048 は 500 文字以上）、署名も速く、RSA のようなパラメータ選択の落とし穴もありません。RSA が今も有用なのは、古いサーバーや機器が Ed25519 を受け付けない場合です —— その場合は 3072 ビット以上を使ってください。2048 ビットは現在の基準では短めです。

生成した鍵は安全ですか？

鍵はブラウザーの `crypto.subtle.generateKey` が生成し、OS の暗号学的に安全な乱数源を使うため強度は十分です。リスクは生成ではなくどこに保存するかにあります：バージョン管理にコミットしない（一度コミットすれば履歴に永遠に残り、削除しても無駄です）、チャットに貼らない、クラウドストレージで同期しない。開発機ならいつでも削除して作り直せます —— 数秒で済みます。公開鍵にはこれらの懸念はありません。公開されるべきものだからです。