Linuxのsshd_config設定完全ガイド｜SSHサーバーを安全に強化する全パラメータと推奨値

VPSやクラウドサーバーを立ち上げてSSHポートをインターネットに公開した瞬間から、ボットによるスキャンとブルートフォース攻撃が始まります。多くの侵害事例を分析すると、根本原因として「sshd_configのデフォルト設定のまま運用していた」という共通点が浮かびます。

sshd_config（SSHデーモンの設定ファイル）を適切に設定するだけで、攻撃の大多数を入口でシャットアウトできます。この記事では、セキュリティの観点から確認すべきパラメータとその推奨値を、現場で使えるレベルで解説します。

sshd_configとは？設定ファイルの役割と場所

sshd_configは、OpenSSHサーバー（sshd）の動作を定義する設定ファイルです。ほぼすべてのLinuxディストリビューションで /etc/ssh/sshd_config に配置されています。

このファイルで制御できる主な項目を整理しておきます。

・認証方式: パスワード認証を許可するか、公開鍵認証のみにするか
・ログイン制限: rootでの直接ログインを許可するか
・接続元制限: 特定のユーザーやIPアドレスからの接続のみ許可
・タイムアウト・試行回数: 認証失敗時の挙動
・暗号アルゴリズム: 使用する鍵交換・暗号・MACの種類
・ポートフォワーディング: SSHトンネルの許可・禁止

設定を変更した後は、sshdを再起動して反映します。ただし、再起動前に必ず現在のSSHセッションとは別のターミナルで接続できることを確認してください。設定ミスでロックアウトされるリスクがあります。

# 設定ファイルの構文チェック（再起動前に必ず実行）
sudo sshd -t

# 構文エラーがなければ再起動
sudo systemctl restart sshd

# 現在の設定を一覧で確認
sudo sshd -T | grep -i 'port\|permit\|password\|pubkey'

攻撃者が狙う設定ミス（敵を知る）

攻撃者がSSHサーバーに侵入する際、最初にチェックするのは次の4点です。

【狙い1】デフォルトのポート22のまま

ポート22は全世界のボットが常時スキャンしています。ポートを変更するだけで攻撃ログの大半（主に自動化されたボット攻撃）をスクリーニングできます。セキュリティ的な根本対策ではありませんが、ノイズを大幅に減らす効果があります。

【狙い2】rootへの直接ログインが許可されている

rootでのパスワードログインが有効であれば、総当たり攻撃で成功した瞬間にサーバー全権限を奪われます。「root直接ログイン禁止＋一般ユーザーでログイン後にsudoで昇格」が原則です。

【狙い3】パスワード認証が有効なまま

パスワード認証が有効だと、辞書攻撃・ブルートフォース攻撃・パスワードリスト攻撃の標的になり続けます。公開鍵認証のみにすれば、秘密鍵を持たない攻撃者は原理的にログインできません。

【狙い4】全IPからの接続を許可

接続元IPを絞れる環境（固定IPのオフィスやVPN）なら、AllowUsersやfirewalldで接続元を制限するだけで攻撃面が劇的に縮小します。

安全なsshd_config設定の実践手順

1. ポート番号の変更（Port）

# デフォルトの22から変更（1024～65535の未使用ポートを選択）
Port 2222

変更後はfirewalldやiptablesでも新しいポートを許可し、旧ポート22への許可を削除してください。接続時は ssh -p 2222 user@hostname のようにポートを指定します。SELinuxを使用している環境では、新しいポートをSSH用として登録する必要があります。

# SELinux環境でのポート追加（例: ポート2222を許可）
sudo semanage port -a -t ssh_port_t -p tcp 2222

# firewalldでの設定変更
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

2. rootログインの禁止（PermitRootLogin）

# 完全に禁止（最も安全な設定）
PermitRootLogin no

# 鍵認証のみ許可する中間設定（デフォルト値）
# PermitRootLogin prohibit-password

PermitRootLogin no に設定した場合、rootへの直接ログインはいかなる方法でも不可になります。必ずsudo権限を持つ一般ユーザーが使えることを確認してから設定してください。sudo設定については、visudoでの正確な設定が重要です。

3. パスワード認証の無効化（PasswordAuthentication）

# パスワード認証を完全に無効化（公開鍵認証のみにする）
PasswordAuthentication no

# 空パスワードでのログインも禁止（デフォルトnoだが明示的に設定）
PermitEmptyPasswords no

# PAMを使用する場合（ChallengeResponseAuthenticationも合わせて）
ChallengeResponseAuthentication no

この設定を行う前に、ログインユーザーの ~/.ssh/authorized_keys に正しい公開鍵が登録されていることを別のターミナルから確認してください。パスワード認証を無効にした後は、公開鍵なしにはログインできません。

4. 接続ユーザーとIPの制限（AllowUsers）

# 特定のユーザーのみSSHログインを許可
AllowUsers yamada@192.168.1.0/24 tanaka

# ユーザーグループで制限する場合
# AllowGroups sshusers

# 特定ユーザーを明示的に拒否する場合
# DenyUsers testuser guestuser

AllowUsers ユーザー名@送信元IP の形式でIPアドレスと組み合わせることができます。接続元が固定IPであれば、これだけで攻撃面を大幅に絞れます。AllowUsersに列挙されていないユーザーはすべてSSHログインが拒否されます。

5. 接続タイムアウトと試行回数の制限

# 認証完了までの最大待機時間（デフォルト: 120秒）
LoginGraceTime 30

# 1接続あたりの認証失敗最大回数（デフォルト: 6）
# 鍵認証のみなら3程度で十分
MaxAuthTries 3

# 同時に保留できる未認証接続数の制限
# 形式: 開始数:確率%:最大数
MaxStartups 5:50:10

# ログイン後にアイドル状態が続いた場合の切断設定
ClientAliveInterval 300
ClientAliveCountMax 2

ClientAliveInterval 300 と ClientAliveCountMax 2 の組み合わせでは、300秒ごとにクライアントの生存確認を行い、2回連続で応答がなければ（合計10分）接続を切断します。放置セッションを自動終了させることで、セキュリティリスクを低減できます。

6. 使用するアルゴリズムの絞り込み

古い脆弱なアルゴリズムを排除し、現在推奨される強力なアルゴリズムのみを使用するよう設定します。

# 鍵交換アルゴリズム（Curve25519を優先）
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# 暗号アルゴリズム（AES-GCMとChaCha20を優先）
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# メッセージ認証コード（HMAC-SHA2系を使用）
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# ホスト鍵（Ed25519とRSAのみ使用、DSAは除外）
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

現在のサーバーのOpenSSHバージョンで対応しているアルゴリズムは ssh -Q kex（鍵交換）、ssh -Q cipher（暗号）で確認できます。古いOpenSSHバージョンでは対応していないアルゴリズムを指定するとsshdが起動しなくなるため、必ず sudo sshd -t で構文チェックを行ってください。

7. ポートフォワーディングと不要機能の制限

# TCP/X11ポートフォワーディングの禁止（不要なら無効化）
AllowTcpForwarding no
X11Forwarding no

# エージェント転送の禁止（踏み台経由の攻撃に悪用されるリスク）
AllowAgentForwarding no

# トンネルデバイスの禁止
PermitTunnel no

# バナーに余計な情報を出さない（バージョン情報を隠す）
Banner none

# ユーザー環境変数の上書きを禁止
PermitUserEnvironment no

# DNS逆引きを無効化（接続速度改善にも有効）
UseDNS no

ポートフォワーディングは攻撃者にSSHトンネルとして悪用されるリスクがあります。業務上不要であれば AllowTcpForwarding no で無効にするのが安全です。ただしSFTPサーバーとして使用する場合はTCPフォワーディングを無効にしても動作します。

設定変更後の確認手順

設定変更を適用した後、以下の手順で正しく動作しているかを確認してください。

・構文チェック: sudo sshd -t でエラーがないことを確認（エラーがあればメッセージが表示される）
・別セッションでの接続テスト: 既存のセッションを切る前に、新しいターミナルから接続確認
・ログの確認: sudo journalctl -u sshd -f でエラーログが出ていないか監視
・設定値の確認: sudo sshd -T で実際に適用された設定値を一覧表示

# 重要パラメータが意図した設定になっているか確認
sudo sshd -T | grep -E "^port|^permitrootlogin|^passwordauthentication|^maxauthtries|^allowusers"

# 接続テスト（詳細ログ付き）
ssh -v -p 2222 username@server_ip

sshd_configの設定に加えて、fail2banを組み合わせると、認証失敗が一定回数を超えたIPを自動ブロックできます。特にパスワード認証を残さざるを得ない環境では有効な多層防御になります。

中小企業でも今日からできること

全設定を一度に変更するのが難しい場合は、影響度の高い順に段階的に適用してください。

・優先度 高: PermitRootLogin no（rootログイン禁止）
・優先度 高: PasswordAuthentication no（鍵認証設定後にパスワード認証を無効化）
・優先度 中: MaxAuthTries 3（試行回数制限）
・優先度 中: AllowUsers（許可ユーザーの明示）
・優先度 低: ポート変更（ノイズ削減効果あり、根本対策ではない）
・優先度 低: アルゴリズム絞り込み（OpenSSHが比較的新しければデフォルトでも安全）

社内のLinuxサーバー設定全体を見直す際は、Linuxサーバー初期セキュリティ設定チェックリストも参考にしてください。SSHの設定だけでなく、ファイアウォール・自動アップデート・監査ログなど25項目を網羅しています。

SSH接続にOTPを組み合わせてさらに強固にする方法は、LinuxのSSH二要素認証設定ガイドで詳しく解説しています。

よくある誤解と注意点

【誤解1】ポートを変えれば安全になる

ポート番号の変更は「自動化されたボット攻撃のノイズを減らす」効果はありますが、本質的なセキュリティ対策ではありません。Nmapなどのポートスキャナで数秒で発見されます。ポート変更は補助的な手段として位置づけ、認証の強化を優先してください。

【誤解2】公開鍵認証は絶対に安全

秘密鍵ファイルが盗まれれば認証を突破されます。秘密鍵にはパスフレーズを設定し、ssh-agent を使う場合のリスクも理解したうえで運用してください。エージェント転送（AgentForwarding）は、踏み台サーバーが侵害された場合に連鎖的な被害を招くことがあるため、必要がなければ無効にします。

【誤解3】設定変更中にログアウトしてしまった

設定変更中に誤って現在のセッションが切れてしまい、新しい設定でログインできなくなるケースがあります。クラウドサーバー（AWS EC2・GCPなど）ではシリアルコンソールや救済モードから設定を修正できます。VPSの場合はプロバイダーのコンソール機能を使います。作業前にスナップショットを取っておくと安心です。

【誤解4】Bastionホストがあれば内部サーバーのSSH設定は不要

Bastionホスト（踏み台サーバー）は内部ネットワークへのアクセスを集約する有効な仕組みですが、各サーバーのsshd_configも適切に設定すべきです。踏み台サーバー自体が侵害された場合の影響を最小化するために、内部サーバーへのAllowUsersでBastionホストのIPのみを許可する設定が有効です。

本記事のまとめ

sshd_configの設定は、一度しっかり整えれば継続的な効果を発揮します。今回紹介した設定の中でまだ未適用のものがあれば、ぜひ今日から着手してみてください。

Linuxのファイル権限管理や一般的なシステム管理コマンドについては、姉妹サイトLinuxMaster.JPでも詳しく解説しています。