VPSを借りたら最初にやる初期設定｜SSH・ufw・自動更新を実機で確認

VPS は、借りた直後から世界中のどこからでも接続できる状態になります。インターネットには、SSH のパスワードを自動で試して回るプログラムが常に動いています。アプリを入れる前に、まず入口を固めておきましょう。

この記事では、Ubuntu の VPS を借りた直後にやる設定を順に解説します。スワップ以外の手順は、国内の VPS の初期状態（root でパスワードログインできる状態）を手元に再現し、実際に実行して確かめました。

先に結論：やることの一覧

手元で確かめた落とし穴は、次の3つです。

• パスワードログインを止める設定は、ファイルの名前によっては効きません。 手元では、99- で始まる名前のファイルに書いても、パスワードログインは有効なままでした。
• SSH のポートを変えても、SSH を再起動するだけでは変わりません。 Ubuntu 24.04 以降は、別のコマンドが必要です。
• ufw の limit と fail2ban は、自分も締め出すことがあります。 締め出されたときに備えて、VPS の管理画面のコンソールの場所を確かめておいてください。

始める前に：各社の初期状態を確かめる

VPS の会社によって、最初にログインするユーザーや、管理画面のファイアウォールの初期状態が違います。公式マニュアルで確認できた内容は次のとおりです。

• 最初のログインが root の会社では、この記事の手順をすべて行います。
• 最初から ubuntu ユーザーでログインする会社では、手順2のユーザー作成を飛ばせます。ただし、ubuntu ユーザーにパスワードでログインしている場合は、手順3の前に必ず鍵を登録してください。 鍵を登録しないまま手順3でパスワードログインを止めると、入れなくなります。鍵の登録のしかたは手順2で説明します。
• どちらの場合も、手順3の確認は行ってください。パスワードログインの設定は、会社が用意した OS のイメージによって違うためです。

管理画面のファイアウォールの違いは、セルフホスト用 VPS の選び方で詳しく比べています。

手順1：パッケージを最新にする

最初に、OS のパッケージを最新にします。

sudo apt update
sudo apt full-upgrade -y

root でログインしている場合、sudo は付けなくても動きます。

途中で、SSH などの設定ファイルについて「新しい版に置き換えるか」を聞く画面が出ることがあります。会社が設定ファイルを書き換えている場合に出るものです。既定の「いまの版を残す（keep the local version currently installed）」を選んでください。 新しい版を選ぶと、鍵を登録する前にパスワードログインができなくなることがあります。

終わったら ls /var/run/reboot-required を実行します。ファイルがあれば、カーネルなどの更新が反映されるよう sudo reboot で再起動してください。

手順2：作業用のユーザーを作り、鍵でログインする

最初のログインが root の場合は、普段の作業に使うユーザーを作ります。ここでは名前を deploy にします。

手元のパソコンで鍵がなければ、先に作ります。 Mac と Windows（PowerShell）のどちらでも、次のコマンドで作れます。

ssh-keygen -t ed25519

VPS の作成時に公開鍵を登録していれば、root の ~/.ssh/authorized_keys に入っています。これを新しいユーザーに写します。以下は root で実行します。

adduser deploy
usermod -aG sudo deploy
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

adduser で決めるパスワードは、鍵を登録したあとは sudo を使うときにだけ入力します。

作成時に鍵を登録していない場合は、root に鍵がないため、上の install の2行は失敗します。代わりに、手元のパソコン（Mac や Linux）から ssh-copy-id deploy@サーバーのIPアドレス を実行してください。パスワードでログインして、公開鍵を登録できます。最初のユーザーが ubuntu の会社では、ssh-copy-id ubuntu@サーバーのIPアドレス です。Windows には ssh-copy-id がないため、VPS の作成時に鍵を登録するのが確実です。

ここで、いま開いている画面は閉じずに、別の画面から鍵でログインできるか確かめます。

ssh deploy@サーバーのIPアドレス

パスワードを聞かれずにログインでき、sudo whoami が root を返せば成功です。

手順3：パスワードログインと root ログインを止める

設定ファイルの名前に注意

Ubuntu の SSH の設定は、/etc/ssh/sshd_config.d/ に置いたファイルで変えるのが基本です。ここで気をつけたいのは、同じ項目が何度も書かれていると、最初に読み込んだ値が使われる点です。ファイルは名前の順に読み込まれます。

VPS によっては、ここに 50-cloud-init.conf という名前のファイルがあり、PasswordAuthentication yes（パスワードログインを許可）と書かれています。サーバーの初期設定を行う cloud-init という仕組みが作るファイルです。

手元で、パスワードログインを止める設定を2通りの名前で置き、実際に効いている値を確かめました。

99- の名前では、先に読み込まれる 50-cloud-init.conf の「許可」が使われ、パスワードログインは止まりませんでした。50 より前に読み込まれる名前にしてください。

設定する

次の内容で /etc/ssh/sshd_config.d/00-hardening.conf を作ります。

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
EOF

KbdInteractiveAuthentication は、別の方式（キーボード対話式）でのパスワード入力を止める設定です。Ubuntu の初期設定でも無効ですが、会社のイメージで変えられていても止まるよう、明示しておきます。

書き間違いがないか確かめてから、SSH を再起動します。

sudo sshd -t
sudo systemctl restart ssh

sudo sshd -t で Missing privilege separation directory: /run/sshd と表示された場合は、sudo mkdir -p /run/sshd を実行してからやり直します。

手元では、restart を実行するまでは設定を変えてもパスワードログインが有効なままでした。再起動を忘れないでください。

本当に効いているか確かめる

サーバーの上では、実際に使われている値を sshd -T で確かめられます。

sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

3つとも no になっていれば成功です。

手元のパソコンからも確かめます。次のコマンドは、鍵を使わずに接続を試し、サーバーが受け付ける方法を表示させます。

ssh -o PubkeyAuthentication=no -o BatchMode=yes deploy@サーバーのIPアドレス true

手元では、設定後に root は鍵を使っても拒否され、deploy は鍵でログインできました。

SSH のポートは変えなくてもよい

パスワードログインを止めれば、総当たりの試行は成功しません。ポートを 22 番から変えると記録に残る試行は減りますが、守りの強さはほとんど変わりません。

それでも変える場合、Ubuntu 24.04 以降は手順に注意が必要です。SSH が「接続が来たら起動する」仕組み（ソケット起動）になっているためです。

手元で Port 2222 を設定に加えて試した結果は次のとおりです。

この2つのコマンドは、Ubuntu が配布する設定ファイルのコメントにも書かれています。ポートを変えるときは、先に ufw と管理画面のファイアウォールで新しいポートを許可してから行ってください（ufw では sudo ufw limit 2222/tcp のように、変えたポートの番号で許可します）。順序を逆にすると、接続できなくなります。

手順4：ufw で使うポートだけを開ける

ufw は Ubuntu に付属するファイアウォールで、初期状態では無効です。入っていない場合は sudo apt install -y ufw で入れます。有効にする前に、必ず SSH を許可してください。 許可せずに有効にすると、いまの接続が切れて入れなくなります。SSH のポートを変えた場合は、下の limit OpenSSH（22番）の代わりに、変えたポートの番号（例：sudo ufw limit 2222/tcp）を許可してください。

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

sudo ufw enable で確認を求められたら、y を入力します。80番と443番は、Web サイトやアプリを公開するときに使います。まだ使わないなら、後から追加しても構いません。

手元では、有効にする前は外から接続できたテスト用の8000番が、有効にした後は接続できなくなりました。SSH は引き続き接続できました。

limit で自分が締め出されることがある

limit は、30秒以内に6回以上接続してきた IP アドレスを拒否する設定です。手元で続けて接続すると、6回目から Connection refused で拒否され、30秒ほど待つと元に戻りました。

scp を何度も続けて実行したり、自動化ツールで短い間に何度も接続したりすると、この制限にかかります。困る場合は、limit の代わりに allow にしてください。

手順5：自動更新の設定を確かめる

Ubuntu には、セキュリティの更新を自動で入れる unattended-upgrades が、最初から入っていて有効です。手元でも、26.04 と 24.04 の両方で有効になっていました。次のファイルの2行が、どちらも "1" なら有効です。

cat /etc/apt/apt.conf.d/20auto-upgrades

ただし、初期状態では次の2点に注意が必要です。

• 自動で再起動しません。 カーネルの更新は、再起動するまで反映されません。
• Docker は更新の対象外です。 自動で入るのは Ubuntu のセキュリティ更新だけで、Docker の公式リポジトリから入れたものは含まれません。Docker は、ときどき sudo apt update && sudo apt upgrade で更新してください。

深夜に自動で再起動させたい場合は、設定ファイルを1つ追加します。

sudo tee /etc/apt/apt.conf.d/52unattended-upgrades-local > /dev/null <<'EOF'
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
EOF

時刻はサーバーのタイムゾーンで決まります。日本時間で指定したいなら、先に sudo timedatectl set-timezone Asia/Tokyo で変えておきます。自動で再起動するなら、Docker のコンテナには restart: unless-stopped を付け、再起動後に自動で立ち上がるようにしておきます。

手順6（任意）：fail2ban を入れる

fail2ban は、ログインに何度も失敗した IP アドレスを一定時間拒否するツールです。パスワードログインを止めていれば必須ではありませんが、試行の記録を減らせます。

sudo apt install -y fail2ban

Ubuntu では、入れるだけで SSH の監視が有効になります。手元で確かめた初期設定は、10分以内に5回失敗すると、10分間拒否でした。

自分の IP アドレスが固定なら、拒否の対象から外しておくと安心です。

sudo tee /etc/fail2ban/jail.d/local.conf > /dev/null <<'EOF'
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 自分のIPアドレス
EOF
sudo systemctl restart fail2ban

• fail2ban は ufw を通さず、自分で nftables に拒否の規則を入れるため、ufw status には表示されません。状況は sudo fail2ban-client status sshd で確かめます。
• Ubuntu 24.04 の発売時の fail2ban には、起動しない不具合がありました。修正版がすでに配布されているため、手順1で更新していれば問題ありません。

手順7（推奨）：スワップを作る

メモリが 1〜2GB のプランでは、メモリが足りなくなったときの逃げ場として、スワップを作っておくと安心です。cloud-init の公式ドキュメントによると、cloud-init は初期状態ではスワップを作りません（会社のイメージによっては作られていることもあります）。まず、あるかどうかを確かめます。

swapon --show
free -h

swapon --show が何も表示せず、free -h の Swap の行が 0B なら、スワップはありません。次の手順で 2GB のスワップファイルを作ります。

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

ファイルの作り方は、Ubuntu のマニュアル（swapon）が「最も移植性の高い方法」としている dd を使っています。この手順は、検証環境でスワップを作れなかったため、手元では試していません。

スワップは、メモリ不足で落ちるのを防ぐための保険です。動作は遅くなるため、常にスワップを使う状態なら、メモリの大きいプランに変えることを考えてください。

最後に確かめること

• 別の画面から、作業用のユーザーで鍵でログインできる
• sudo sshd -T で、パスワードログイン、キーボード対話式、root ログインが no
• sudo ufw status で、SSH と使うポートだけが許可されている
• VPS の管理画面のファイアウォールでも、同じポートだけを許可している
• VPS の管理画面のコンソールから、ログインできることを確かめた

最後の項目は、締め出されたときの命綱です。設定が終わったら、一度コンソールを開いて確かめておいてください。

次にやること

入口を固めたら、アプリを公開する準備に進みます。

• Docker Compose と Caddy でアプリを HTTPS 公開する
• n8n を VPS にセルフホストする
• Dify を VPS にセルフホストする

これから VPS を選ぶ場合は、管理画面のファイアウォールの違いも含めて セルフホスト用 VPS の選び方で比べています。

サービス	管理画面のファイアウォール	公式のテンプレート	新規申込
ABLENET VPS大阪	記載なし管理画面のファイアウォールは公式の仕様に記載がない。公式は OS のファイアウォールでの制限を案内している	Docker、Dify、n8n	受付中脆弱性への対応では「新規申込の停止は予定していない」と案内
ConoHa VPS国内（都市名の記載なし）	初期状態で拒否外からの接続は、許可するグループを付けるまで届かない。IPv4・IPv6とも設定できる	Docker、Dify、n8n	受付中脆弱性への対応で 10月19日に新規申込を停止し、10月23日に再開
KAGOYA CLOUD VPS未確認（公式ページに記載なし）	初期状態は全許可適用していないサーバーは全許可。適用すると、許可したもの以外を拒否する	Docker、Dify（n8nは確認できず）	停止中脆弱性への対応で 10月19日から新規申込を停止。再開時期は未定
さくらのVPS石狩の価格（東京・大阪はこれより高い）	一部だけ制限初期状態は SSH（22番）だけ許可。ただし IPv6 は全許可で、32768番以上のポートも常に許可される。スタートアップスクリプトで作成した場合は初期状態でオフ	Docker、Dify、n8n	一部のみ受付脆弱性への対応で 10月16日に全リージョンの新規申込を停止。10月23日に石狩だけ再開し、東京・大阪は再開時期未定。石狩の 4GB〜16GB は 10月2日から在庫切迫の告知あり
シンVPS国内（都市名の記載なし）	未確認初期状態は公式ページで確認できなかった。オフにすると全ポートが許可される	Docker、Dify、n8n	受付中新規申込の停止の告知は見当たらない
WebARENA Indigo東京	未確認初期状態は公式ページで確認できなかった	なし（Docker、Dify、n8nは確認できず）	停止中脆弱性への対応で 10月21日から新規申込を停止。再開時期は未定。平常時も平日16時〜翌9時と土日祝は申し込めない
XServer VPS国内（都市名の記載なし）	初期状態で拒否契約直後はすべての接続を拒否する設定。IPv6 の扱いは未確認	Docker、Dify、n8n	受付中9月17日から停止していた新規受付を 10月6日に再開。2GB は 7月14日に受付停止が告知され、再開の告知は見当たらない。10月21〜22日は脆弱性への対応で公式サイトと管理画面を停止し、10月23日に新規申込を再開

2026年10月23日に各社の公式ページとお知らせで確認しました。テンプレートは、Docker・Dify・n8n をまとめて入れられる公式の仕組み（アプリイメージ、スタートアップスクリプトなど）の有無です。

各社の出典（公式ページ）を見る

• ご利用料金（ABLENET VPS 公式）確認日 2026年10月23日
• VPSの仕様（ABLENET VPS 公式）確認日 2026年10月23日
• AIセルフホストVPS（ABLENET 公式）確認日 2026年10月23日
• お知らせ一覧（ABLENET VPS 公式）確認日 2026年10月23日
• 料金・スペック（ConoHa VPS 公式）確認日 2026年10月23日
• セキュリティグループ（ConoHa VPS ドキュメント）確認日 2026年10月23日
• スタートアップスクリプト（ConoHa VPS 公式）確認日 2026年10月23日
• 新規申込受付再開のお知らせ（ConoHa VPS 公式）確認日 2026年10月23日
• 料金・機能（KAGOYA CLOUD VPS 公式）確認日 2026年10月23日
• セキュリティグループの設定（KAGOYA サポート）確認日 2026年10月23日
• 新規お申し込み受付停止のお知らせ（KAGOYA 公式）確認日 2026年10月23日
• 料金・仕様（さくらのVPS 公式）確認日 2026年10月23日
• パケットフィルター（さくらのサポート情報）確認日 2026年10月23日
• Linuxカーネルの脆弱性への対応状況（さくらのVPS 公式）確認日 2026年10月23日
• 石狩リージョンの在庫についてのお知らせ（さくらのVPS 公式）確認日 2026年10月23日
• 料金・仕様（シンVPS 公式）確認日 2026年10月23日
• OS・アプリイメージ一覧（シンVPS 公式）確認日 2026年10月23日
• パケットフィルターの設定（シンVPS 公式）確認日 2026年10月23日
• ニュース一覧（シンVPS 公式）確認日 2026年10月23日
• 料金（WebARENA Indigo 公式）確認日 2026年10月23日
• 新規お申し込み一時停止のお知らせ（WebARENA 公式）確認日 2026年10月23日
• 移行キャンペーン（申込できる時間の記載、WebARENA 公式）確認日 2026年10月23日
• 料金一覧（XServer VPS 公式）確認日 2026年10月23日
• OS・アプリイメージ一覧（XServer VPS 公式）確認日 2026年10月23日
• 契約直後のセキュリティ対策（XServer VPS 公式）確認日 2026年10月23日
• 2GBプランの新規受付停止のお知らせ（XServer VPS 公式）確認日 2026年10月23日
• 新規受付再開のお知らせ（XServer VPS 公式）確認日 2026年10月23日