SSHを安全にする基本｜鍵認証とrootログイン禁止の始め方

「SSHのパスワード認証、そろそろ鍵にしたほうがいいよな」。 頭では分かっているのに、なかなか手が付かない設定の代表格ですよね。設定を間違えて自分がサーバーに入れなくなったら——そう考えると、動いている本番にはなおさら触りたくなくなります。

その慎重さは、まったく正しい感覚です。SSHの設定変更は、手順を間違えると本当に自分を締め出してしまう作業だからです。だからこそ、大事なのは気合いではなく「締め出されない順番」を知っておくことです。

この記事では、SSHを安全にする最初の一歩——鍵認証への切り替えとrootログインの禁止を、一人運用でも自分を締め出さずに進められる順番で、一緒に整理していきます。

結論：SSHの安全化は、①今の接続を切らずに別のセッションを1つ確保する → ②鍵認証で入れることを先に確認する → ③そのうえでパスワード認証とrootログインを止めるの順で進めます。「先に鍵で入れることを確かめてから、古い入口を閉じる」。この順番さえ守れば、締め出しの事故はほぼ防げます。

設定ファイルの場所やコマンドは、OS（Ubuntu／Rocky／Amazon Linux など）やバージョンで少しずつ違います。この記事の順番と考え方を土台に、細かい書式は必ず自分の環境の公式情報で確認してください。

なぜ「パスワード認証」と「rootログイン」が狙われやすいのか

まず、なぜこの2つを見直すのかを一言だけ。責める話ではなく、理由が分かると安心して手を動かせます。

• パスワード認証は、総当たり（ブルートフォース）で延々と試せてしまいます。インターネットに公開されたSSHポートには、日常的に自動化されたログイン試行が飛んできます。パスワードが強くても、「試し続けられる入口」が開いていること自体がリスクです。
• rootログインの許可は、当てるべき相手（ユーザー名）が最初から分かっている状態です。攻撃側は「root」というユーザー名は決め打ちできるので、あとはパスワードだけを狙えばよくなります。

鍵認証に切り替えると「パスワードを試す」という攻撃自体が通らなくなり、rootログインを止めると「rootを直接狙う」入口が消えます。これがSSH安全化の、いちばん効く2手です。

順番に進める（自分を締め出さないために）

ここからが本番です。ポイントは、設定を変えても、今つないでいるセッションはすぐには切れないという性質を使うことです。今の接続を「命綱」として残したまま、別の窓で新しい入り方を確かめます。

① 今の接続を残したまま、作業用のセッションを用意する

いちばん大事な保険です。今SSHでつないでいる窓（セッション）は、作業が全部終わって安全確認できるまで、絶対に閉じないでおきます。

• 設定変更後の確認は、別のターミナルで新しくログインし直して行います。今の窓を残しておけば、新しい入り方でしくじっても、生きている窓から設定を元に戻せます。
• 可能なら、コンソール（クラウドのシリアルコンソールや、物理・仮想のコンソール画面）から入る経路も確認しておくと、さらに安心です。SSHが完全に閉じてしまったときの最後の入口になります。

「元に戻せる窓がもう1つある」。この状態を作るだけで、以降の作業の怖さが大きく減ります。

② 鍵認証で入れることを「先に」確認する

パスワード認証を止めるのは、鍵で入れると確認できた後です。順番を逆にしないのが肝心です。

大まかな流れはこうです（コマンドの書式は環境の公式情報で確認してください）。

1. 手元（自分のPC）で鍵ペアを作る。秘密鍵は自分のPCに厳重に保管し、公開鍵だけをサーバーに渡します。秘密鍵は誰にも渡さない・サーバーに置きっぱなしにしない、が基本です。
2. 公開鍵をサーバーの対象ユーザーに登録する（~/.ssh/authorized_keys に追記）。このファイルとディレクトリの権限（パーミッション）が緩いと鍵認証が働かないことがあるので、~/.ssh は本人だけがアクセスできる状態にします。
3. 別のターミナルから、鍵を使って実際にログインできるか試す。ここで入れれば、新しい入口は開通です。
4. 秘密鍵にはパスフレーズ（鍵自体のパスワード）を付けておくと、鍵ファイルが漏れても即座には使われにくくなります。

もし鍵でうまく入れないときは、慌てず①の生きている窓に戻って原因を確認します。多くは公開鍵の貼り付けミスか、権限（パーミッション）まわりです。

③ そのうえで、パスワード認証とrootログインを止める

鍵で入れることが確認できて初めて、古い入口を閉じます。設定ファイル（多くは /etc/ssh/sshd_config、環境により /etc/ssh/sshd_config.d/ 配下の追加ファイル）を編集します。

• 変更前に、設定ファイルのバックアップ（コピー）を取る。戻すときにこれが命綱になります。
• 主に見直すのは次のあたりです（項目名は共通ですが、既定値や置き場所は環境で異なります）。
• パスワード認証を無効化する設定（PasswordAuthentication no）
• rootでの直接ログインを禁止する設定（PermitRootLogin no）
• 公開鍵認証が有効になっているかの確認（PubkeyAuthentication yes）
• 設定の文法チェックをしてから反映する。多くの環境で sshd -t のような文法確認ができます。ここでエラーを潰しておくと、反映で足をすくわれません。
• 設定を反映（SSHサービスの再読み込み・再起動）したら、必ず①の窓は残したまま、別の窓で鍵ログインをもう一度確認します。問題なく入れたら、ようやく最初の窓を閉じて大丈夫です。

rootを止めた後は、一般ユーザーでログインしてから必要に応じて権限昇格（sudo など）する運用に切り替わります。日々の作業がこの形になっているかも、あわせて確認しておきましょう。

ここも一緒にやると効く（余裕があれば）

②③までできれば、SSHの安全性はぐっと上がります。時間に余裕があるとき用に、相性のいい一手も置いておきます。無理に一度にやらなくて大丈夫です。

• ログイン試行の集中を和らげる仕組み（fail2ban のように、失敗が続くIPを一時的に遮断するツール）を入れると、ノイズのようなログイン試行を減らせます。
• 接続元をアクセス制限で絞る（ファイアウォールやセキュリティグループで、SSHを許可するIPを限定する）。固定IPの拠点からしか入らないなら、これが一番シンプルに効きます。
• ポート番号を既定から変えるのは、自動化された無差別スキャンを少し減らす効果はありますが、これ自体は本質的な防御ではありません。鍵認証・root禁止・接続元制限が本命で、ポート変更は「おまけ」と考えておくと判断を誤りません。

影響：この2手で、何が変わるか

鍵認証とrootログイン禁止をやり切ると、目に見えて変わることがあります。

• 「パスワードを試し続ける」攻撃が、そもそも成立しなくなる。ログに並ぶ大量のログイン失敗が、実害につながりにくくなります。
• rootを直接狙う入口が消える。誰が入ったのか（どの一般ユーザーか）も追いやすくなり、あとで「誰が何をしたか」を確認しやすくなります。
• 棚卸しや引き継ぎのときに説明しやすくなる。「SSHは鍵認証のみ・root禁止です」と一言で言える状態は、監査やベンダーとのやり取りでも安心材料になります。

逆に、パスワード認証を開けたまま・rootログインを許したまま公開し続けると、実害が出ていなくても「開いている入口」を抱え続けることになります。今日この2手を進めておくと、その不安を静かに一つ減らせます。

明日やること：まず1台で「鍵で入れる」を確認する

いきなり全サーバーを設定変更する必要はありません。明日できる、いちばん小さくて安全な一歩はこれです。

1. 今いちばん大事な1台を選ぶ（練習を兼ねるなら、止まっても困らない検証用の1台でも可）。
2. 今の接続を残したまま、手元で鍵ペアを作り、公開鍵をそのサーバーに登録する。
3. 別のターミナルから、鍵でログインできるか試す。ここまでで「新しい入口が開いた」状態を確認する。
4. 入れることを確認できたら、そこで一区切り。パスワード認証とroot禁止の反映は、落ち着いた時間帯に②③の順で。
5. うまくいったら、その手順を自分の環境用のメモに1枚書き残す。2台目からはそれをなぞるだけになります。

今日は「鍵で入れることを確認する」まででも十分な前進です。古い入口を閉じるのは、確認できた後でゆっくりやれば大丈夫です。

「SSH安全化」チェックリスト

本番で慌てないための、平時の確認用です。コピーして、自分の環境に当ててみてください。

最低ラインは、「鍵で入れることを確認してから、パスワード認証とrootログインを止めている」——この順番が守れていれば、締め出しの事故はほぼ防げます。

• 作業中、今の接続とは別に「元に戻せる窓（セッション）」を確保しているか
• （可能なら）SSHが閉じたときの最後の入口（コンソール）を確認してあるか
• 鍵ペアを作り、公開鍵だけをサーバーに登録しているか（秘密鍵は手元に厳重保管）
• ~/.ssh と authorized_keys の権限が本人のみに絞られているか
• 鍵で実際にログインできることを確認してから、古い入口を閉じているか
• 設定変更の前に sshd_config のバックアップを取っているか
• 反映前に設定の文法チェック（sshd -t など）をしているか
• パスワード認証（PasswordAuthentication no）を無効化しているか
• rootの直接ログイン（PermitRootLogin no）を禁止しているか
• 反映後、別の窓で鍵ログインを再確認してから最初の窓を閉じているか

全部に○が付かなくても大丈夫です。まずは「鍵で入れる確認」と「順番を守る」の2つから埋めていきましょう。

よければ、こちらも

SSHの安全化は、サーバーまわりの棚卸しや引き締めと一緒にやると効果がまとまります。あわせて1枚にしておくと、次の点検がぐっと楽になります。

• 退職者アカウントの棚卸し｜権限を最小化する一人運用の手順：不要なアカウントや過剰な権限を減らす話。鍵認証・root禁止と同じ「入口を絞る」考え方です。
• 不正アクセスの疑いがあるときの初動と保全｜まず止める順番：もし何か起きたときの初動。SSHの入口を締めておくと、この事態自体を減らせます。
• セキュリティパッチ適用の進め方｜壊さず一人で回す手順：SSHを含むミドルウェアを安全に更新する型。「戻せる形で反映する」考え方は共通です。

SSHの設定変更は、怖がって後回しにしてしまいがちな作業です。でも、怖さの正体は「締め出し」で、それは順番を守れば避けられます。先に鍵で入れることを確かめてから、古い入口を閉じる。たったこれだけです。 今日は1台で「鍵で入れる」を確認するところまでで十分です。その一歩が、あなたのサーバーの入口を、静かに一つ堅くしてくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。