SSHの鍵をなくす前にやっておくこと — 私は何もやっていなかった

前の記事で、サーバーに鍵で入れるところまで終わりました。パスワードでのログインは止めて、rootで入る道も塞ぎました。

→ VPSを契約したらやる初期設定4つ

そのとき手元に残るのは、秘密鍵のファイル1つです。数百バイトのテキストで、消そうと思えば一瞬で消えます。ゴミ箱を空にしても、パソコンを買い替えても、うっかり .ssh ごと消しても同じです。

この記事は、そのファイルを失う前にできることの話です。失ったあとの話ではありません。理由は単純で、失ったあとにできることが、ほとんど残っていないからです。

私は一度、自分のサーバーから閉め出されたことがあります。鍵の設定を試している最中に何度もログインに失敗して、fail2ban に自分の家のIPアドレスをブロックされました。あのとき助かったのは技術ではなく、事業者のコンソールを先に確認しておいたという、それだけのことでした。

そのときはまだ、鍵そのものは手元にありました。もし鍵まで一緒に失っていたらどうなっていたか、というのがこの記事の出発点です。

そして、先に書いておきます。この記事を書くために調べたら、自分が何ひとつやっていないと分かりました。 鍵をなくした経験もありません。だからこの記事は「私はこうして助かった」ではなく、点検の記録です。

なくしたあとに残るもの

秘密鍵を失うと、SSHでは入れません。パスワードは止めてあるので、代わりの入口もありません。

残っているのは、事業者の管理画面にあるコンソールだけです。ブラウザからサーバーの画面に直接つなぐ機能で、SSHとは別の経路で動いています。前の記事の0番で確認しておいたものが、ここで唯一の入口になります。

そこから何をするかというと、新しい鍵を作って、その公開鍵をサーバーに置き直す作業です。ここで問題が2つ出ます。

1つ目は、公開鍵が長いことです。sshd(8) のマニュアルは、この行についてこう書いています。

Note that lines in this file can be several hundred bytes long (because of the size of the public key encoding) up to a limit of 8 kilobytes, which permits RSA keys up to 16 kilobits. You don't want to type them in; instead, copy the id_dsa.pub, id_ecdsa.pub, id_ecdsa_sk.pub, id_ed25519.pub, id_ed25519_sk.pub, or the id_rsa.pub file and edit it.

公式が「打ち込みたくはないだろう」と書いています。コピーして貼れ、というのが指示です。

2つ目は、そのコンソールで貼れないことです。現在のConoHaのサポートページには、こう書かれています。

コンソールではコピー・ペーストが利用できません。ログインパスワードやコマンドを貼り付けしたい場合はテキスト送信機能をご利用ください。

代わりの機能は用意されています。それでも、打ち込むなと書かれているものを、コピペの効かない画面で扱うことになります。これがConoHa以外でどうなっているかは、私は確認していません。

パスフレーズを付けていて、それを忘れた場合はもっと単純です。

ちなみに私の場合、鍵を失っても止まるのはサーバーに入ることだけです。gitのリモートを確認したら、2つのリポジトリとも https:// でした。SSHのリモートを使っている人は、pushも同時に止まります。

以下、備えを3つ書きます。どれも、鍵が手元にあるうちにやるものです。

1. 秘密鍵をバックアップする

バックアップする対象は、思っているよりずっと小さいものです。手元で作った ed25519 の秘密鍵は7行・399バイトでした。テキストファイル1個です。

公開鍵のほうは要りません。秘密鍵から作り直せるからです。ssh-keygen(1) の -y に、こう書かれています。

-y This option will read a private OpenSSH format file and print an OpenSSH public key to stdout.

これを実際に試しました。公開鍵ファイルを退避して削除し、-y で作り直したものと比べたところ、diff の差分はゼロでした。鍵の末尾に付いているコメントまで一致します。コメントは秘密鍵ファイルの中にも入っているためです。

ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pub

公開鍵ファイルを消したまま接続もしてみましたが、こちらも普通にログインできました。守るべきものは秘密鍵1つだけ、と考えて構いません。

置き場所については、私に書けることがありません。鍵の管理サービスを使っていないので、良し悪しを比べられないからです。ただ1つだけ、構造として言えることがあります。秘密鍵はサーバーへの入口そのものなので、コピーした先の数だけ入口が増えます。バックアップを増やすことと、守る場所を増やすことは同じ作業です。

書き戻したときは、権限を見てください

これは私の推測ではなく、実際に出るところまで見ました。秘密鍵のパーミッションを 644 にして接続すると、サーバーに届く前にクライアント側が止めます。

Permissions 0644 for '/tmp/sshdtest/keyA' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

そのあと Permission denied (publickey,keyboard-interactive). が出て終わります。鍵は正しいのに入れません。書き戻したら chmod 600 を確認してください。ストレージやUSBを往復させた場合に実際に緩くなるのかは、私はその経路を試していません。

私は2か所に持っていますが、バックアップではありません

手元を調べたら、本番用の秘密鍵が同じパソコンの中に2つありました。WSL側とWindows側で、どちらも同じバイト数で、diff は完全に一致します。

これをバックアップと呼ぶことはできません。WSLで作った鍵をWindowsへコピーした作業の副産物だと思われますし、なにより2つとも同じ1台の中にあります。このパソコンが壊れたら、両方が同時に消えます。

Windows側のファイル権限がLinuxと同じ意味を持つのかも、確認していません。表示上の値は見えますが、それはNTFSのアクセス制御をGit Bash越しに見た数字なので、さきほどの chmod 600 の話と同じ土俵には乗せられません。

なお、Windows側にはもう1本、契約したときに事業者が発行した古い形式の鍵が残っていました。事業者からもらった鍵と、自分で作った鍵は別物です。同じフォルダに並んでいると、どちらがどれか分からなくなります。

2. authorized_keys に2本目を置く

ここが、この記事でいちばん書きたかったところです。前の記事では鍵を1本しか作っておらず、この話は一度も出していません。

このファイルは、1行に1つの鍵を書きます。そして行数の制限は書かれていません。sshd(8) は、このファイルの形式をこう説明しています。

Each line of the file contains one key (empty lines and lines starting with a `#' are ignored as comments).

空行と # で始まる行は無視されるので、どの鍵が何なのかをその場にメモとして残せます。

実際に2本並べて試しました。使い捨てのサーバーを立てて、authorized_keys に2行書き、それぞれの秘密鍵で接続しています。結果は、1行目の鍵でも2行目の鍵でもログインできました。サーバー側のログを詳細（LogLevel VERBOSE）にしておくと、何行目の鍵で通ったかまで出ます。

Accepted key ED25519 SHA256:7PCt+zBtdAnQiqoSXv1PzYYrs9c+CWIcw8ERhGBSwZo found at /tmp/sshdtest/authorized_keys:1

Accepted key ED25519 SHA256:QNtiE9nUb5ho+qkS7DBW0Nz/PH9FS4Zhd2nM3FZHTio found at /tmp/sshdtest/authorized_keys:2

行番号が出るので、2本目を置いたあとで「どちらの鍵で入られたか」を後から確認できます。2本目を置くのが不安な人には、これが直接の答えになると思います。

この作業の重さは、鍵が手元にあるかどうかで桁が変わります。あるうちなら、いつもどおりログインして1行足すだけです。失ったあとでも同じことはできますが、コピペの効かないコンソールで長い1行を打ち込む作業になります。

手順は2つです ― 鍵を作る、1行足す

まず、2本目の鍵を作ります。ここでファイル名を指定し忘れると、いま動いている1本目が消えます。

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_backup -C "backup-2026-08"

-C に用途と日付を書いておくと、あとで見分けがつきます。コメントは秘密鍵ファイルの中にも入っているので、さきほどの -y で公開鍵を作り直したときも一緒に戻ってきます。

次に、この2本目の公開鍵をサーバーの authorized_keys に足します。使う記号は >> です。

手元で、2本目の公開鍵の中身を表示してコピーします。

cat ~/.ssh/id_ed25519_backup.pub

1本目の鍵でいつもどおりログインして、サーバー側で追記します。2コマンドです。

echo >> ~/.ssh/authorized_keys
echo '<コピーした1行をここに貼る>' >> ~/.ssh/authorized_keys

1行目は、改行を1つ送っているだけです。これを飛ばすと、条件によっては2本とも使えなくなります。

理由は、ファイルの末尾に改行があるとは限らないからです。無い状態で追記すると、1本目の行の末尾に2本目がそのままくっつきます。

ssh-ed25519 AAAA…KEY1 key1ssh-ed25519 AAAA…KEY2 key2

こうなると、1本目も2本目も鍵として読めません。 手元で試したところ、この状態でも wc -l は1つ増えるので、行数を数えても気づけませんでした。

先に改行を1つ送っておけば、末尾に改行があってもなくても、2本が別々の行として並びます。このとき、見た目は2通りに分かれます。

末尾に改行が無かった場合  → その改行が1本目の行末になる。空行はできない
末尾に改行が有った場合    → 空行が1つ増える（authorized_keys では読み飛ばされます）

どちらでも構いません。 大事なのは空行の有無ではなく、ssh- で始まる行が2つ、別々に並んでいることです。

足したら、行を数えるのではなく、中身を見てください。

cat ~/.ssh/authorized_keys

ssh- で始まる行が2つ、それぞれ独立して並んでいれば成功です。1行にくっついていたら、上のくっつきが起きています。

足すときにもう1つ。既にある authorized_keys の所有者とパーミッションは変えないでください。sshdはログインを受ける前にそこを見て、持ち主や権限がおかしければ鍵を黙って無視します。この挙動は前の記事で扱いました。上のように自分のユーザーでログインして追記するぶんには、持ち主は変わりません。

2本目を、1本目の隣に置かないでください

作った2本目の秘密鍵を、1本目と同じ ~/.ssh に並べたままにすると、この記事の1番で書いたのと同じ形になります。パソコンが壊れたとき、.ssh ごと消したとき、2本とも一緒に消えます。それは、この記事が主眼にしている場面そのものです。

どこに置くのがいいかは、やはり私には書けません。管理サービスを使っていないので、良し悪しを比べられないからです。書けるのは構造だけです。同じ入れ物の中で本数を増やしても、その入れ物ごと失う筋書きには効きません。 2本目が備えになるのは、1本目とは別のところに置いたときです。そして置いた先の数だけ、守る場所も増えます。

置いたら、その場で確かめてください

2本目の鍵は、置いただけでは備えになりません。それが使えると分かるのは、1本目が使えなくなった日です。その日に初めて試すのは、いちばんやりたくない順番です。

順番としては、動くことを確かめてから移してください。 移した先で初めて試すと、失敗したときに「鍵が悪いのか、置き場所が悪いのか」が分かりません。作った場所のまま一度通してから、別のところへ移します。

確かめ方は、前の記事の0番と同じです。今つながっている接続は閉じずに、もう1つターミナルを開いて、2本目の鍵だけを指定して入ってみます。失敗しても、開いたままの接続が残ります。

ssh -i ~/.ssh/id_ed25519_backup -o IdentitiesOnly=yes example.com

うまくいかないときに困るのが、クライアント側に出るメッセージです。鍵が登録されていない場合も、authorized_keys が丸ごと無い場合も、出るのは同じ1行でした。

Permission denied (publickey,keyboard-interactive).

原因の切り分けはここではできません。理由はサーバー側のログに出ているので、そちらを見てください。

ただし、鍵を増やすと入れなくなることがあります

これを併記せずに「2本目を作れ」と書くのは無責任だと思うので、先に出します。

これも試しました。使い捨てのサーバーに、登録していない鍵7本を -i で明示して並べ、最後に有効な鍵を指定して接続すると、こうなります。

Received disconnect from 127.0.0.1 port 22222:2: Too many authentication failures

有効な鍵を持っているのに、入れませんでした。しかもメッセージは回数の話しかしていないので、原因が鍵の順番にあることが読み取れません。

さらに悪いことに、この失敗の連続は fail2ban から見れば攻撃と同じ形をしています。私が閉め出されたときと同じ状態に、鍵を増やしただけで入れてしまいます。

だから ~/.ssh/config まで書いて、ひとまとまりです

対処は、どのサーバーにどの鍵を使うかを先に書いておくことです。

Host example.com
  IdentityFile ~/.ssh/id_ed25519
  IdentityFile ~/.ssh/id_ed25519_backup
  IdentitiesOnly yes

2本目も書いてあることに注意してください。 IdentitiesOnly yes は「ここに書いたものだけ」という意味なので、1本目しか書かないと、せっかく登録した2本目が一度も提示されません。 備えたつもりで、いざというときに使えない状態になります。

そして2本目のパスは、実際に置いた場所に書き換えてください。 さきほど「1本目の隣に置かない」と書きました。移したなら、ここも移した先を指す必要があります。設定ファイルは移動について来ません。 存在しないファイルを指したまま固定されると、いざというときに使えないという、いま書いたのと同じ結果になります。

IdentityFile は複数書けます。ただし挙動が独特で、ssh_config(5) はこう注意しています。

Multiple IdentityFile directives will add to the list of identities tried (this behaviour differs from that of other configuration directives).

後から書いたほうが勝つのではなく、足し算になります。増やしすぎれば、さきほどの6回に近づきます。

IdentitiesOnly のほうは、既定が no です。つまり何も書かないと、設定に書いた鍵のほかに、エージェントが持っている鍵まで提示されます。yes にすると、指定したものだけになります。

さきほど -f で付けた id_ed25519_backup は既定の名前から外れているので、-i か設定ファイルで名指ししないと使われません。2本目を作った時点で、この設定ファイルが要る側に回っています。

2本目を作る話と、どの鍵を使うか書く話は、切り離して勧められません。

私は置いていません

そして、本番のサーバーに鍵が何本あるのかを、この記事を書いている時点で確認していません。記録の上では1本しか作っていないはずです。

古いroot用の公開鍵がサーバーに残っている、という記録もあります。ただしrootでのログインは止めてあるので、これは2本目には数えられません。残しておく意味も特に無く、片付ける対象のほうです。

3. 後からパスフレーズを付ける

前の記事で、私はパスフレーズを付けていないと書きました。そして「これから作るなら、付けたうえで ssh-agent を使うほうがいい」とも書きました。

やり方を書かないまま、記事を終えていました。 ここで閉じます。

作り直す必要はありません。ssh-keygen(1) にこう書かれています。

The passphrase can be changed later by using the -p option.

-p Requests changing the passphrase of a private key file instead of creating a new private key. The program will prompt for the file containing the private key, for the old passphrase, and twice for the new passphrase.

ssh-keygen -p -f ~/.ssh/id_ed25519

手元で試したところ、付けたあとも公開鍵はまったく同じでした。フィンガープリントも一致します。書き換わるのは秘密鍵ファイルだけなので、サーバー側の作業は発生しません。 authorized_keys を触る必要はありません。

もう1つ分かったことがあります。パスフレーズが掛かっているかどうかは、1行目を見ても分かりません。付ける前も後も -----BEGIN OPENSSH PRIVATE KEY----- のままです。私が判別に使ったのは、空のパスフレーズで開いてみて失敗するかを見る方法でした。ファイルの中身をもっと踏み込んで読めば分かるのかどうかは、試していません。

なお、-N と -P でパスフレーズを引数として渡すこともできます。私が測ったときはそちらを使いましたが、コマンドの履歴に残るので、手元で1本付けるだけなら対話のプロンプトに任せるほうが素直です。

ここで注意が要ります。エージェントを起動しただけでは、鍵は入りません。ssh-agent(1) にこうあります。

The agent initially does not have any private keys.

入れる方法は2つあって、ssh-add で手で入れるか、ssh_config(5) の AddKeysToAgent を設定して自動で入れてもらうかです。そして後者の既定値は no です。何も書かなければ、何もしてくれません。

つまり手順としては、パスフレーズを付ける、~/.ssh/config に AddKeysToAgent を書く、というところまでが1セットになります。設定ファイルを書く話は、2本目の鍵の節と同じ場所に着地します。

預ける時間も区切れます。-t で寿命を秒や 1h30m のような書式で指定できて、指定しなければ既定は forever です。ログアウトするまで入れっぱなしになります。

私は付けていません。エージェントも動いていません

2026年8月27日に手元を確認した結果です。

秘密鍵は2本あります。個人用と、本番のサーバー用です。どちらも空のパスフレーズで開けました。つまり、どちらにもパスフレーズが掛かっていません。

SSH_AUTH_SOCK は設定されておらず、ssh-add -l は Could not open a connection to your authentication agent. を返しました。~/.ssh/config は、そもそも存在しません。

前の記事で、パスフレーズを付けても ssh-agent を使えば自動化と共存できる、と書きました。その ssh-agent が、書いた本人の環境で動いていません。しかも「まだやっていない」は昔の話ではなく、今日測った現在形です。

使わないと決めたもの

調べる過程で出てきたけれど、この記事では勧めないものを書いておきます。

エージェント転送は使いません。 ssh -A で、手元のエージェントを接続先のサーバーからも使えるようにする機能です。公式は ssh(1) と ssh_config(5) の2か所に、同じ文面の警告を置いています。

Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

前半が条件で、後半が結果です。接続先のサーバーでファイル権限を迂回できる人がいる場合に、その人が手元のエージェントへ届く、という話になっています。鍵そのものは取られませんが、その鍵で認証する操作を代わりにやられます。ssh(1) のほうには、代替として jump host を挙げる一文が続きます。既定はオフなので、何もしなければ安全な側にいます。オンにしろと書いてある解説を見かけても、この記事の範囲では要りません。

パスワードでのログインには戻しません。 前の記事で止めたものを、鍵を失ったときの保険として復活させるのは、あの記事の主張と正面から矛盾します。逃げ道はコンソールのほうで確保します。

鍵の管理サービスについては、使っていないので書けません。

この手順が前提にしていること

私の環境ではそうだった、というだけのものを並べます。

引用したマニュアルは、WSL2のUbuntu 24.04に入っている OpenSSH_9.6p1 Ubuntu-3ubuntu13.18 のものです。2026年8月27日に読みました。手元の版が違えば文面も違うので、man ssh-keygen などで確認してください。

動かして確かめた部分は、すべて手元に立てた使い捨てのサーバーで測っています。本番のサーバーでは何も試していません。

まだ確かめていないこと

• 本番の authorized_keys に鍵が何本あるか。見ていません
• 古いroot用の公開鍵が、本番に今も残っているか。記録があるだけです
• パスフレーズを付けたあとの実運用。まだ1日も使っていません
• バックアップから書き戻したときに、権限が実際に緩くなるのか。往復させていません
• Windows側の ssh-agent とファイル権限の扱い
• ConoHa以外の事業者のコンソールが、コピペを許すかどうか

fail2ban に自分のIPアドレスを除外させる設定も、前の記事で「まだ入れていない」と書いたまま、今も入れていません。この記事の2番で書いた失敗の連続は、そこにも当たります。

まとめ

1. 秘密鍵をバックアップする       数百バイトのテキスト1個。.pub は要らない
2. authorized_keys に2本目を置く  1行1鍵。増やすなら ~/.ssh/config も書く
3. 後からパスフレーズを付ける      ssh-keygen -p。公開鍵は変わらない

どれも、腰を据えれば1つ30分ほどの作業です。そして3つとも、鍵が手元にあるうちにやるほうが、はるかに簡単です。失ってからでも同じことはできますが、コピペの効かない画面で長い1行を打ち込む作業に変わります。

私の状態を並べておきます。

前の記事の最後に、閉め出されたときに助かったのは技術ではなく逃げ道だった、と書きました。今回調べて分かったのは、その逃げ道が今もコンソール1本しか無いということでした。

鍵の備えは、失う前にやるから備えになります。失ったあとにも同じことはできますが、コピペの効かない画面で長い1行を打ち込む作業に変わります。そして備えたかどうかは、失った日に初めて分かります。

次にやること

この記事と同じ形の話を、証明書で書きました。設定した日には正しさを確認できない、という点が共通しています。

→ VPSにドメインを向けてHTTPSにする — 自動更新は未確認だった

鍵の作り方、公開鍵の置き方、コンソールの確認は、こちらに書いています。

→ VPSを契約したらやる初期設定4つ