SSH ポートを 22 から変更:何が解決し、何が解決しないか

SSH をポート 22 から動かすと攻撃量は大きく減り、そしてほとんど何からも守ってくれません。締め出されずに行う手順と、多くの解説が省く 2 つの段階。

約 7 分で読めます

率直な要約

SSH を 22 から動かせば、ログイン失敗の量は一晩で 9 割ほど落ちます。同時にそれはセキュリティ対策ではなく、対策だと思って扱うことこそ、「もう終わった」と考えた管理者のサーバーが侵害される道筋です。

どちらも真なのは、別々の問いに答えているからです。量の低下は現実であり、測定でき、有用です。防御としての効果は、30 秒でも調べる相手に対してはほぼゼロです。

やる価値はあるか。たいていはあります——ノイズ低減として、本物の防御と並べて。決してその代わりにではなく。

実際に止まるもの

SSH への攻撃トラフィックの圧倒的多数は、たった 1 つのことをする無差別スキャナーから来ます。広い IP レンジにわたってポート 22 に接続し、応答したものに資格情報を試す。ポートスキャンはしません。全インターネットで 1 つのポートを調べるコストは 65,535 個を調べるより桁違いに安く、22 番にいるマシンは彼らを忙しくさせるのに十分すぎるほどあるからです。

52200 に移せば、あなたはその母集団から完全に外れます。グラフは崖のように落ち、認証ログは数時間ごとに回るのをやめ、その中から本物の出来事を見つけることが再び可能になります。

この最後の点は過小評価されています。読めるログはインシデント対応の最中に本物の価値を持ちますが、1 日 3,000 件の失敗がある状態では、それを持っていません。

止まらないもの

全ポート範囲をスキャンする相手は、数分であなたを見つけます。SSH は平文で名乗ります——バージョンバナーはサービスが最初に送るものです——ので、全ポートを走査してバナーを読むスキャナーは、一度目であなたのサービスを正しくラベル付けします。

Shodan と Censys はまさにそれを継続的に行い、結果を検索可能な索引として公開しています。あなたの非標準の SSH ポートは数日のうちにそこへ載り、誰にでも見つけられる状態になります。

つまり、無差別のボットに対してはポート変更は効きます。あなたを選んだ相手に対しては、数分を余計にかけさせるだけです。そして弱いパスワード、漏れた鍵、パッチの当たっていない sshd、同じホスト上の脆弱なアプリケーションについては、何も変えません。

積極的な副作用もあります。珍しいポートは物事を壊します。外向きの 22 を許可している企業ファイアウォールは外向きの 52200 を遮断し、そしてあなたはそれを、デプロイできなくなった同僚から知らされます。

締め出されずに変更する

多くの解説が省く段階が 2 つあり、現代のディストリビューションではどちらもあなたを締め出します。RHEL 系での SELinux のポートラベル付けと、sshd がもはや自分では待ち受けない最近の Debian・Ubuntu での systemd ソケット起動です。

現在のセッションを開けたまま、順に進めてください:

bash
NEWPORT=52200

# 1. まずファイアウォール——sshd がどこかへ移る前に
sudo ufw allow ${NEWPORT}/tcp                                          # ufw を使う Debian/Ubuntu
sudo firewall-cmd --permanent --add-port=${NEWPORT}/tcp && sudo firewall-cmd --reload   # RHEL 系

# 2. SELinux:ポートにラベルを付ける。さもないと sshd はバインドを拒否する(RHEL 系)
sudo semanage port -a -t ssh_port_t -p tcp ${NEWPORT} || \
  sudo semanage port -m -t ssh_port_t -p tcp ${NEWPORT}

# 3. sshd に伝える。22 はいったん残す——2 ポートで、切断されないように
printf 'Port 22\nPort %s\n' "$NEWPORT" | sudo tee /etc/ssh/sshd_config.d/20-port.conf
sudo sshd -t                            # リロード前に構文検査

# 4. ソケット起動:最近の Debian/Ubuntu では sshd 自身はバインドしない
systemctl is-enabled ssh.socket 2>/dev/null && \
  echo 'ssh.socket が有効です——ListenStream はそちらで上書きします。下の注記を参照'

sudo systemctl reload ssh               # RHEL 系では 'sshd'

移行を完了させる

次に、2 本目の端末から新しいポートで検証します——ssh -p 52200 user@server——他に何かを触る前に。それが動いてから初めて、設定から Port 22 を外し、もう一度リロードし、古いファイアウォール規則を閉じます。

そのうえで、古いポートを保存していたものすべてを更新します:~/.ssh/config のエントリ、デプロイスクリプト、CI ランナー、Ansible インベントリ、監視チェック、バックアップジョブ、そしてチームのドキュメント。夜間バックアップを壊すポート変更は、変更しないより悪いです。

新しいポートが自ネットワークの外から動くと確認するまで、ポート 22 を外さないでください。LAN の内側ではどちらでも動き、人が「大丈夫だ」と自分を納得させるのはまさにその状況です。

何と組み合わせるべきか

ポート変更が減らすのはノイズです。届いてくる試行は依然として何かが処理しなければなりません——そしてポート変更後に届く試行は、あなたを名指しで探した相手のものであり、それこそ本当に気にすべきものです。

SSH Protector は 22 を前提とせず、sshd の実効設定から実際の SSH ポートを検出します。すでに移設済みのサーバーも設定なしで覆われ、あとでポートが再び変わっても規則は作り直されます。

読めるログのためにポートを変える。それでも見つけてくるトラフィックのために、防御は残す。

FAQ

SSH はどのポートに移すべきですか?
1024 より上の空いているポートなら何でも——52200、47820、空いているもので構いません。1024 未満のポートはバインドに root が必要で、sshd では問題になりませんが選択肢は狭まります。22 の次に誰もが最初に試す 2222 は避け、決める前に ss -tlnp で何も待ち受けていないことを確認してください。
sshd_config を変えたのに、なぜ SSH はまだ 22 で待ち受けているのですか?
Ubuntu 22.10 以降、Debian 12 以降では ssh.socket が有効な場合があり、そのときは待ち受けソケットを systemd が所有し、Port ディレクティブは無視されます。systemctl is-enabled ssh.socket で確認し、有効ならソケットユニットで ListenStream を上書きしてください——まず空の ListenStream= で継承された既定値を消します。
SSH ポートを変えるとき SELinux の設定は必要ですか?
SELinux が enforcing の RHEL、CentOS、AlmaLinux、Rocky、Fedora では必要です——sshd はラベルのないポートへのバインドを拒否します。リロード前に semanage port -a -t ssh_port_t -p tcp <ポート> を実行してください。これを飛ばすのは RHEL 系でポート変更が失敗する最も一般的な原因で、しかもリロードした後になって失敗します。
非標準の SSH ポートは本当に安全ですか?
22 番とまったく同程度に安全で、背景ノイズがはるかに少ないだけです。ポートはアクセス制御ではありません。SSH はバージョンバナーを平文で送るため、全範囲スキャナーは一度目でサービスを識別しますし、Shodan は非標準 SSH ポートを継続的に索引化しています。安全性は試行を処理するものから生まれるのであって、どこに届くかから生まれるのではありません。

それでも届く試行を塞ぐ

エージェントは SSH が実際に使っているポートを検出し、そこへ届いた送信元を遮断します。1 台永年無料、カード不要。