SSH鍵認証を初めて設定する日に、先に知っておきたい落とし穴

はじめに：鍵認証は「設定順」で事故が決まる

SSHの鍵認証は、パスワード認証より安全で、毎回の入力も減らせます。ただ、初めて設定するときは「手順どおりにやったのに入れない」「パスワード認証を閉じたらサーバーに入れなくなった」といったつまずきが起こりがちです。この記事では、コマンドの羅列ではなく、初回に気をつけたい点を順番に整理します。

1. 作業中のセッションは絶対に閉じない

いちばん大事な注意点です。リモートのサーバーで sshd の設定を変えるとき、いま繋がっているセッションを残したまま、別の端末から新しく接続して確認してください。設定ミスで入れなくなっても、残しておいた最初のセッションから元に戻せます。

クラウドやVPSなら、コンソール接続やレスキューモードが使えるか、事前に確認しておくと安心です。物理サーバーで現地に行けない場合は、なおさら慎重に進めましょう。

2. 鍵ペアは「手元の端末」で作る

鍵は秘密鍵と公開鍵のペアです。作るのは、接続する側の手元の端末です。サーバー上で作って秘密鍵を持ち帰る、という流れは避けましょう。秘密鍵が通信経路やサーバーに残る余計なリスクが生まれます。

• 秘密鍵：自分の端末だけに置く。他人に渡さない、チャットやメールに貼らない
• 公開鍵：サーバーに登録するもの。拡張子は通常 .pub で、見られても問題ない

鍵の種類は、特別な事情がなければ Ed25519 が扱いやすく、現在広く使われています。古い環境との互換性が必要な場合は RSA を選ぶこともあります。その場合は十分な鍵長を指定してください。

3. パスフレーズは付ける

鍵生成のときにパスフレーズを聞かれます。面倒で空にしたくなりますが、付けておくことをおすすめします。パスフレーズがあれば、万一ノートPCの紛失やバックアップ経由で秘密鍵ファイルが漏れても、すぐには悪用されません。

毎回入力するのが負担なら、ssh-agent を使って、一度入力したら一定時間は使い回す方法があります。「パスフレーズなしで便利に」ではなく「パスフレーズありで便利に」を目指すのが基本です。

4. 公開鍵の登録は ssh-copy-id が楽

公開鍵は、サーバー側のユーザーの ~/.ssh/authorized_keys に1行として追記します。手作業でもできますが、改行が入ったり途中で切れたりしやすいので、ssh-copy-id コマンドが使える環境ならそれを使うのが確実です。このコマンドは、必要なディレクトリを作り、追記まで行ってくれます。

手作業で登録する場合は、次の点を確認してください。

• 公開鍵が1行のまま貼られているか
• 既存の行を上書きしていないか（追記にする）
• ログインしたいユーザーのホームにある authorized_keys か

5. パーミッションが原因で入れないことが多い

鍵認証がうまくいかない原因として非常に多いのが、ファイルやディレクトリの権限です。sshd は、権限が緩すぎると安全でないとみなして、鍵を無視することがあります（設定の StrictModes が有効な場合）。

• ~/.ssh ディレクトリ：自分だけが読み書きできる状態（700）
• authorized_keys：自分だけが読み書きできる状態（600 など）
• ホームディレクトリ：他人から書き込めない状態にしておく
• 手元の秘密鍵：自分だけが読める状態（600）。緩いと ssh クライアント側が使用を拒否する

「ちゃんと登録したのに聞かれる」ときは、まず権限を疑うと解決が早いです。

6. 先に鍵でログインできることを確認してから、パスワード認証を止める

鍵認証の目的の一つは、パスワードによる総当たり攻撃を無効にすることです。そのためには sshd_config で PasswordAuthentication を no にしますが、これは鍵でのログインが確実にできると確認してからです。

確認の手順は次のとおりです。

• 別の端末（または別セッション）から、鍵を使って接続できるか試す
• 接続時に ssh -v を付けて、どの鍵が使われ、どの認証方式で通ったかを見る
• 問題がなければ設定を変更し、sshd の設定ファイルの文法チェック（sshd -t）を行う
• 設定を反映したあと、さらに別の新しいセッションでもう一度ログインを試す

なお、ディストリビューションによっては、設定ファイルを分割して読み込む仕組み（sshd_config.d など）があり、そちらの記述が優先されて、変更したつもりが効いていないことがあります。反映後は、実際の有効値を sshd -T で確認すると確実です。

7. root ログインの扱いも一緒に見直す

鍵認証を整えるついでに、root での直接ログインを許可するかどうかも見直しましょう。一般ユーザーでログインして必要なときだけ権限を上げる運用にすると、攻撃対象を減らせます。ただし、これも自分がsudoを使えることを確認してから変更してください。順番を間違えると、管理者権限を失います。

8. 秘密鍵の管理とバックアップ

鍵認証は、秘密鍵を持っていることが身元の証明になります。つまり、秘密鍵をなくすと入れなくなり、盗まれると他人に入られます。

• 端末を買い替えるときの鍵の移行方法を決めておく
• 複数の端末を使うなら、端末ごとに鍵を分けると、紛失時にその鍵だけを無効にできる
• 不要になった公開鍵は authorized_keys から削除する
• 秘密鍵をクラウドの共有フォルダや公開リポジトリに置かない

とくに、うっかり Git リポジトリに秘密鍵をコミットする事故は珍しくありません。一度公開した鍵は、削除しても漏れたものとして扱い、作り直してください。

9. うまくいかないときの切り分け

入れないときは、慌てて設定を変えず、まずログを見ます。

• クライアント側：ssh -v（必要なら -vvv）で、どの鍵を試し、どこで拒否されたかを確認する
• サーバー側：認証ログ（ディストリビューションにより /var/log/auth.log や journalctl など）を確認する
• 鍵が複数ある場合：ssh -i で使う鍵を明示し、~/.ssh/config に Host ごとの設定を書く

サーバー側のログには「権限が不正」「鍵が受け付けられない」などの理由が書かれていることが多く、原因の特定に役立ちます。

まとめ：手順より「安全に戻れる状態」を優先する

SSH鍵認証の初回設定で大切なのは、次の3点です。

• 作業中のセッションを残し、別セッションで必ず確認する
• 秘密鍵にはパスフレーズを付け、手元だけで管理する
• 鍵でのログインを確認してから、パスワード認証や root ログインを止める

どれも難しい作業ではありませんが、順番を誤ると自分を締め出してしまいます。「いつでも元に戻れる」状態を保ちながら、一つずつ確かめて進めてください。