Ubuntu 初期化フルガイド：ユーザー・SSH・fail2ban のセキュリティ設定
深夜3時、ターミナルに表示された「Permission denied」というエラーをじっと見つめながら、背中に冷や汗が流れていました。
サーバーに入れなくなったのです。SSH 設定を軽い気持ちで変更し、逃げ道を残し忘れただけで。
あれは3年前、初めて VPS を買ったときのことでした。今思えば、当時の操作はまさに教科書級の反面教師でした。root で直接ログインし、パスワードは誕生日、SSH はデフォルトの 22 ポート、ファイアウォール？聞いたこともない。結果はどうなったか。サーバーは稼働して2週間も経たないうちにスキャンで荒らされ、ログは総当たり攻撃の痕跡だらけでした。
正直なところ、多くの初心者は VPS を買った直後にこう考えます——とにかくソフトを入れてプロジェクトをデプロイしたい、と。ユーザー管理？SSH 強化？面倒だから後回しでいいや、と。しかし、その「後回し」にしたことこそが、サーバーがどれだけ長く生き延びられるかを左右します。
この記事がやることはただ一つ。ゼロから、買ったばかりの Ubuntu サーバー（22.04 または 24.04）を、安全に使える状態に構成することです。ユーザー権限、SSH 強化、fail2ban による自動 BAN まで、一つも漏らしません。各ステップで「なぜこうするのか」を説明します。コマンドをただコピペさせるだけにはしません。
だいたい 10 分で、このフローを一通り終えられます。終えたあとは、あなたのサーバーのセキュリティレベルはネット上の「裸同然」のマシンの 80% を超えるはずです。
一、初期化前の準備作業
作業を始める前に、まずツールを揃えましょう。ローカルで SSH 鍵ペアを生成しておく必要があります。
なぜパスワードではなく鍵を使うのか？ 端的に言えば、パスワードは総当たりで破られますが、鍵はほぼ不可能だからです。256 ビットの Ed25519 鍵を総当たりで破る時間は、宇宙の年齢より長くかかります。
鍵の生成
現在は Ed25519 アルゴリズムが推奨されます。古い RSA より安全で、鍵も短くて済みます。生成コマンドはとてもシンプルです：
# macOS / Linux
ssh-keygen -t ed25519 -C "[email protected]"
# Windows（PowerShell、OpenSSH クライアントが必要）
ssh-keygen -t ed25519 -C "[email protected]"実行すると、鍵をどこに保存するか、パスワードを設定するかを聞かれます。そのままエンターでデフォルトパスを使えば大丈夫です。パスワードは必要に応じて——設定すればより安全ですが、接続のたびに入力が必要になります。
生成が終わると、ローカルに2つのファイルができます：
~/.ssh/id_ed25519—— 秘密鍵、絶対に漏らしてはいけない~/.ssh/id_ed25519.pub—— 公開鍵、あとでサーバーにアップロードする
ターミナルツールについては、macOS 標準の Terminal で十分です。Windows なら Windows Terminal か MobaXterm がおすすめです。ここは本題ではないので、詳しくは触れません。
二、ユーザーと権限の管理
まず root でサーバーにログインします（root で直接ログインするのはこれが最後です。あとで禁止します）：
ssh root@あなたのサーバーIPなぜ root を使わないのか？
一言で言えば、結果が深刻すぎるからです。
root 権限は強すぎて、ファイルを1つ消し間違えたり、設定を1つ変え間違えたりするだけで、システム全体が壊れます。さらに厄介なのは、多くの攻撃スクリプトが root アカウントを狙って総当たり攻撃を仕掛けてくることです。root を SSH ログインにさらすのは、ハッカーに大きな的を差し出すようなものです。
日常の操作は一般アカウントで行い、権限が必要なときに sudo を使う。これが Linux の基本的なセキュリティ原則です。
デプロイ用ユーザーの作成
私は deploy という名前が好きです。「デプロイ専用」という意味です。好きな名前を使っても構いません：
# ユーザー作成（パスワードと情報の設定を求められる）
adduser deploy
# sudo 権限を付与
usermod -aG sudo deployUbuntu はパスワードの設定とユーザー情報の入力を求めてきます。パスワードは覚えやすいものを設定し、その他の情報はそのままエンターでスキップして大丈夫です。
新しいユーザーへの公開鍵のアップロード
次に、ローカルの公開鍵をこの新しいアカウントにアップロードします。ローカルマシンで実行してください：
# macOS / Linux
ssh-copy-id deploy@あなたのサーバーIP
# Windows（PowerShell）
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@あなたのサーバーIP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"そして deploy でログインできるかテストします：
ssh deploy@あなたのサーバーIPログインできましたか？よし、これ以降は deploy で操作し、root には戻らないようにします。root 権限が必要なときは sudo を付けてください。
複数ユーザーのシナリオ
サーバーをチームの複数人で使う場合は、一人ずつ独立したアカウントを作成できます。たとえば：
# 同僚の zhangsan にアカウントを開設
adduser zhangsan
usermod -aG sudo zhangsan
# 公開鍵をアップロード（本人がローカルで実行）
ssh-copy-id zhangsan@あなたのサーバーIP各自が自分のアカウントを使えば、操作記録を追跡でき、問題が起きても原因を調べやすくなります。
三、SSH のセキュリティ強化
このステップは初期化全体で最も核心となる部分であり、「自分を締め出す」惨事が最も起きやすい箇所でもあります。
警告：SSH 設定を変更する前に、必ず現在の接続を開いたままにし、同時に別のターミナルウィンドウを開いてテストしてください。こうすれば、間違えても別のウィンドウから復旧できます。
SSH 設定ファイルの編集
sudo nano /etc/ssh/sshd_config核心パラメータを一行ずつ解説
1. Port ポート
Port 22 # デフォルト値、変更推奨22 ポートは全ネットスキャンの第一の標的です。高位ポート（たとえば 22222 や 54321）に変えることで、大半の無差別スキャンを避けられます。
Port 54321注意：クラウド事業者（Alibaba Cloud、Tencent Cloud、AWS など）を使っている場合、ポートを変更したらセキュリティグループ／ファイアウォールで新しいポートを開放するのを忘れずに。さもないと接続できません。
2. PermitRootLogin root ログインの禁止
PermitRootLogin no # 必須の変更なぜか？先ほど述べたとおり、root はハッカーの第一の標的だからです。これを禁止すれば、攻撃面が一気に大きく減ります。
3. PasswordAuthentication パスワードログインの無効化
PasswordAuthentication no # 鍵ログインのみ許可これが総当たり攻撃を防ぐ鍵です。秘密鍵さえ漏れなければ、たとえパスワードを知られても他人はログインできません。
4. その他のセキュリティパラメータ
MaxAuthTries 3 # パスワードの試行は最大3回
ClientAliveInterval 300 # 5分間操作がなければ切断
ClientAliveCountMax 2 # 無応答は最大2回までこれらのパラメータは、長時間アイドルの接続がリソースを占有するのを防ぎ、総当たり攻撃の試行回数も制限できます。
設定検証の三段階
設定を変更したら、すぐに再起動せず、まず検証します：
第一段階：設定の構文をテスト
sudo sshd -t何も出力されなければ良い知らせです。構文に問題ないということです。
第二段階：新しいウィンドウで接続テスト
現在のウィンドウはそのままにして、別のターミナルウィンドウを開き、新しいポートと deploy アカウントで接続します：
ssh -p 54321 deploy@あなたのサーバーIP接続できましたか？設定が有効になり、しかも自分を締め出していないということです。
第三段階：問題ないことを確認してサービスを再起動
sudo systemctl restart sshd
# または
sudo systemctl restart ssh再起動後、もう一度新しいウィンドウでテストします。正常にログインできることを確認して、初めてこのステップが本当に完了したことになります。
ワンポイント
変更後に接続できなくなっても、慌てないでください。クラウド事業者のコンソールから VNC でログインし、設定を元に戻して、サービスを再起動すれば大丈夫です。これが、私が常に「SSH 設定変更前に接続を1つ開いたままにする」ことを強調する理由です。
四、fail2ban による自動 BAN
ここまでの SSH 設定は、主に総当たり攻撃を防ぐものです。しかし、誰かが粘り強くパスワードを試し続けてきたら？そのときは fail2ban の出番です。
fail2ban とは？ ログを自動で監視し、疑わしい IP を BAN するツールです。誰かが連続でパスワードを間違えた？一定時間自動でブロックします。シンプルで荒削りですが、効果は抜群です。
インストールと起動
sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2bansshd jail の設定
fail2ban は「監獄（jail）」という概念で、サービスごとの監視ルールを管理します。SSH にはデフォルトで sshd jail があります。
ローカル設定ファイルを作成します（デフォルト設定を直接変更しないこと。アップグレードで上書きされます）：
sudo nano /etc/fail2ban/jail.local以下の内容を書き込みます：
[sshd]
enabled = true
port = 54321 # あなたの SSH ポートに変更
maxretry = 3 # 3回失敗で BAN
findtime = 600 # 10分以内
bantime = 3600 # 1時間 BANパラメータの説明：
maxretry：許容する失敗回数。デフォルトは5で、私はより厳格に3にしています。findtime：時間ウィンドウ、単位は秒。600 秒 = 10 分以内に3回失敗するとトリガーされます。bantime：BAN の時間、単位は秒。3600 = 1 時間。86400（1日）やそれ以上に設定することもできます。
変更後はサービスを再起動します：
sudo systemctl restart fail2banBAN 状況の確認
# すべての jail の状態を確認
sudo fail2ban-client status
# sshd jail の詳細を確認
sudo fail2ban-client status sshd現在 BAN されている IP の一覧が表示されます。
IP の BAN 解除
自分が誤って BAN されてしまった場合（デバッグ中にパスワードを間違えすぎたなど）、次のように解除できます：
sudo fail2ban-client set sshd unbanip あなたのIP応用：カスタムルール
fail2ban は SSH だけでなく、Nginx、Apache、MySQL などのサービスも保護できます。設定方法は同様で、対応する jail を作成するだけです。これは詳しく語ると長くなるので、ここでは触れる程度にとどめます。
五、バージョン差分早見表
Ubuntu 22.04 と 24.04 の2バージョンは、初期化フローはおおむね一致していますが、いくつかの細かい差異があります。
主要な差分の対照
| 項目 | Ubuntu 22.04 LTS | Ubuntu 24.04 LTS |
|---|---|---|
| カーネルバージョン | 5.15 | 6.8 |
| OpenSSH バージョン | 8.9 | 9.6 |
| デフォルト Python | 3.10 | 3.12 |
| systemd バージョン | 249 | 255 |
| サポート期間 | 2027年4月まで | 2029年4月まで |
実際の影響
良い知らせ：本記事の初期化フローは、両バージョンで完全に共通です。SSH 設定パス、fail2ban のインストール方法、ユーザー管理コマンドは、いずれも変わりません。
注意すべき点：
-
OpenSSH 9.x（24.04） はデフォルト設定がやや厳格で、一部の古い暗号アルゴリズムが無効化されています。古いバージョンの SSH クライアントで 24.04 に接続すると問題が起きることがありますが、クライアントをアップグレードすれば解決します。
-
クラウド事業者のイメージ：一部のクラウド事業者の 22.04 イメージには監視や管理のスクリプトがプリインストールされており、あなたの設定と競合する可能性があります。公式のクリーンイメージを使うか、初期化前に既存のサービスを確認することをおすすめします。
-
アップグレードの問題：すでに稼働中の 22.04 サーバーがある場合、24.04 にアップグレードする前にスナップショットを取っておくのがよいでしょう。
do-release-upgradeは大半の場合成功しますが、セキュリティ設定のようなものは、念には念を入れた方が安心です。
どう選ぶか？
- 新規プロジェクト：迷わず 24.04 を。サポート期間が長く、ソフトウェアバージョンも新しいです。
- 既存プロジェクト：特定バージョン（たとえば Python 3.10）に依存している場合は 22.04 を。
- 安定志向：22.04 はすでに成熟しており、落とし穴もほぼ踏み尽くされています。
- 新しもの好き：24.04 にはより良いハードウェアサポートや性能最適化などの新機能があります。
まとめ
ここまで色々と語りましたが、この初期化フローの核心ポイントを振り返りましょう：
セキュリティ三点セット：
- 一般ユーザーを作成し、root ログインを禁止する
- SSH のポートを変更し、パスワードを禁止、鍵のみ許可する
- fail2ban で疑わしい IP を自動 BAN する
操作の原則：
- 設定変更前に接続を1つ開いたままにする
- 各ステップで検証し、急いで再起動しない
- 秘密鍵は絶対に漏らさない
検証チェックリスト：
- deploy アカウントで新しいポートから SSH ログインできる
- root アカウントではログインできない
- パスワードログインが無効化されている
- fail2ban サービスが正常に動作している
この設定はサーバーセキュリティの第一歩にすぎません。今後はさらにファイアウォール（UFW）の設定、Docker のインストール、アプリのデプロイ……といった話題が続きますが、これらはまた別の機会に。
このチュートリアル通りに操作して問題があれば、ぜひコメントで議論しましょう。3年前のあの深夜3時、自分を締め出してしまった惨事を、あなたには二度と経験してほしくないのです。
Ubuntu サーバーの初期化セキュリティ設定
ゼロから安全な Ubuntu サーバーを構成。ユーザー管理、SSH 強化、fail2ban による BAN を含む
⏱️ 目安時間: 10 分
- 1
ステップ1: SSH 鍵を生成する
ローカルマシンで Ed25519 鍵ペアを生成します：
• コマンド：ssh-keygen -t ed25519 -C "[email protected]"
• 秘密鍵は ~/.ssh/id_ed25519 に保存（絶対に漏らさない）
• 公開鍵は ~/.ssh/id_ed25519.pub に保存（アップロード用） - 2
ステップ2: 一般ユーザーを作成する
サーバーにログインしたらデプロイ用ユーザーを作成します：
• ユーザー作成：adduser deploy
• sudo 権限を付与：usermod -aG sudo deploy
• 覚えやすいパスワードを設定する - 3
ステップ3: 公開鍵をアップロードしてログインを確認する
ローカルマシンで実行します：
• ssh-copy-id deploy@サーバーIP
• ログイン確認：ssh deploy@サーバーIP
• deploy で正常にログインできたら、以降はこのアカウントで操作します - 4
ステップ4: SSH 設定を変更する
/etc/ssh/sshd_config を編集します：
• Port 54321（高位ポートに変更）
• PermitRootLogin no（root ログインを禁止）
• PasswordAuthentication no（パスワードログインを無効化）
• MaxAuthTries 3
• ClientAliveInterval 300
注意：変更前に接続を1つ開いたままにしておくこと！ - 5
ステップ5: SSH を検証して再起動する
三段階の検証法：
• 構文テスト：sudo sshd -t
• 新しいウィンドウでテスト：ssh -p 54321 deploy@サーバーIP
• 問題なければ再起動：sudo systemctl restart sshd - 6
ステップ6: fail2ban をインストールして設定する
総当たり攻撃の IP を自動 BAN します：
• インストール：sudo apt install fail2ban -y
• /etc/fail2ban/jail.local を設定
• maxretry=3, bantime=3600 を設定
• サービス再起動：sudo systemctl restart fail2ban
FAQ
SSH ポートはどの番号にするのが適切？
SSH 設定を変更したら接続できなくなったら？
fail2ban は自分自身を BAN することはある？
Ubuntu 22.04 と 24.04 で初期化に違いはある？
鍵ログインはパスワードログインよりどれくらい安全？
SSH ポートを 22 に戻してもいい？
5分で読めます · 公開日: 2026年3月27日 · 更新日: 2026年6月1日
関連記事
Cloudflare Pro か Business か？3 つの軸で判断するアップグレード判断ツリー
Cloudflare Pro か Business か？3 つの軸で判断するアップグレード判断ツリー
Docker ミラーソース速度テスト実践：3 つの方法 + 自動切り替えスクリプト
Docker ミラーソース速度テスト実践：3 つの方法 + 自動切り替えスクリプト
社内ネットワーク Docker pull タイムアウトのトラブルシューティング：DNS・プロキシ・ミラー加速の完全ガイド
コメント
GitHubアカウントでログインしてコメントできます