前回の「NetplanによるIP固定化」に引き続き、初のUbuntuサーバー（WordOps用入国）と格闘している管理人です。
IPが固定できたら、次にやるべきは「SSHの堅牢化（セキュリティ強化）」ですよね。
「sshd_config を開いて、パスワード禁止にしてポート番号を変えるだけでしょ？そんなのCentOS Stream 9で何百回とやってきたわ」
そうタカをくくって突っ込んだ結果、Ubuntu特有の「systemdのステルス罠」に引っかかり、ポート変更が一切反映されずに無事死亡しました。
設定項目の文字自体はRHEL系と同じなのに、裏の動かし方が全然違います。今回は、CentOS Stream 9ユーザーがUbuntu（22.04 / 24.04以降）でSSHを設定する際、必ず踏み抜くドツボとその回避手順をメモしておきます。
1. 公開鍵の登録（ここはいつも通り）
まずはPCの公開鍵（id_ed25519.pub など）を登録します。ここはRHEL系でもDebian系でも変わりません。お作法通りに。
mkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
# 公開鍵を貼り付けて保存
chmod 600 ~/.ssh/authorized_keys2. sshd_configの編集と「第一の罠」
OpenSSHサーバーをインストールします。
sudo apt update
sudo apt install -y openssh-server続いて設定ファイルを開きます。
sudo nano /etc/ssh/sshd_configいつもの3点セットを書き換えます。
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no🚨 CentOSユーザーが「あれ？」となる第一の罠：.d ディレクトリの影
CentOS Stream 9でもお馴染みの設定分割用ディレクトリ /etc/ssh/sshd_config.d/ ですが、Ubuntu（特にクラウド環境や自動構築スクリプト経由）では、最初からこの中に初期設定ファイルが転がっているケースが多いです。 本体の sshd_config をどれだけ綺麗に書き換えても、.d の中のファイルが後から設定を上書きして「なぜかパスワードでログインできてしまう」というゾンビ現象が起きます。効かない場合は .d の中身も一緒に確認しましょう。
3. 【最重要】ポート変更と「第二の特大罠（ssh.socket）」
セキュリティのためにポート番号をデフォルトの22から 50022 などに変更します。
誰もが sshd_config に Port 50022 と書いたら、sudo systemctl restart ssh をしますよね。
残念ながら、Ubuntuではこれだけだと100%ポートが変わりません。
最近のUbuntuは、SSHをサービス単体ではなく ssh.socket（systemdのソケット管理） で待ち受ける仕様になっています。そのため、ポート変更の主権は sshd_config ではなく systemd 側にあります。
正しくポートを変更するには、以下のコマンドでソケット設定を上書き（ドロップインファイルを作成）する必要があります。
sudo systemctl edit ssh.socket画面が開いたら、以下を追記して保存します。
[Socket]
ListenStream=
ListenStream=50022※1行目の空の ListenStream= が超重要です。これがないと「22番と50022番の両方で待ち受ける」という中途半端な状態になります。過去の遺産（22番）を一度クリアするための小手先テクニックです。
4. 設定の適用（テストを忘れたら即切腹）
設定が終わったら、systemdをリロードしてソケットを再起動します。
sudo systemctl daemon-reload
sudo systemctl restart ssh.socketパスワードを聞かれず、カチッと一発でログインできれば大成功です！
まとめ
「LinuxなんだからSSHの設定なんてどこも一緒だろ」という油断を、見事なアッパーカットで粉砕してくれたUbuntuの ssh.socket 仕様。
慣れ親しんだ sshd_config を無視してソケット側でポートを握りつぶす挙動には一瞬キレそうになりましたが、仕組みさえ分かってしまえば、次からはドロップインファイルを1枚書くだけでスマートに管理できます。
狙い通りのポートで、公開鍵だけでセキュアに繋がり、パスワード攻撃をシャットアウトできればこちらのもの。
結論：なんか動いたからヨシ！
これでネットワークに続き、ログイン経路の砦もセキュアに構築できました。
とはいえ、サーバーのセキュリティを万全にするためには、認証周りだけでなく、OSの土台そのものを最新に保つ「あの儀式」が欠かせません。
次回は、OSの安全性を担保するためのシステムアップデート編をお送りします！
コメント