サーバー、ドメイン、復旧経路を準備する
公開IPv4、SSHの22番ポート、sudoを使える初期アカウント、自分が管理するドメインを用意します。新規作成なら次節で先に鍵を生成します。空のVMを既に作った場合は、現在使える接続から鍵を追加する分岐を選びます。
手元のコマンドはLinux、macOS、WSLのBash、サーバーのコマンドはSSH先で実行します。203.0.113.10とapp.example.comは文書用の例なので全て置き換えてください。初期ユーザーubuntuも提供元に合わせます。変更前に復旧コンソールを開き、イメージのファイアウォール方針を確認します。OracleのUbuntuはUFWと異なる手順です。
SSH鍵を作成し、最初の接続を確認する
手元で専用鍵を作り、パスフレーズを設定します。同名なら上書きせず別名を使います。.pubが公開鍵で、秘密鍵は手元に残します。
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub新規VPSの場合は、この公開鍵を登録してUbuntu 24.04を作成します。初期ユーザーを確認し、下のホスト鍵確認へ進んでください。既存サーバー用の次の2ブロックは使いません。
既に作成した空のVPSでは、接続できているセッションを残します。手元の別ターミナルから、現在使える認証で公開鍵をコピーします。existing_vps_keyを現在の鍵名に変更します。パスワードまたはSSHエージェントを使う場合は-i ~/.ssh/existing_vps_keyを省き、サーバーの認証方針は変えません。
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub現在のサーバー接続内で公開鍵を検証し、初期アカウントのauthorized_keysへ追記します。既存行を残し、末尾に改行がない場合も分離します。アクセスが全くなければ、まず提供元の復旧手順を使います。
if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
mkdir -p ~/.ssh
chmod 700 ~/.ssh
printf '\n' >> ~/.ssh/authorized_keys
cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
fiどちらの分岐でも初回接続のホスト鍵を、信頼できる復旧コンソール上の同じ種類の鍵と照合します。Ed25519の場合はコンソールで次を実行します。
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub手元から新しい鍵で別の接続を開きます。成功まで以前のアクセスは閉じません。
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10次の管理ユーザー用に、手元の別ターミナルから公開鍵を送ります。既存VMの分岐で一時ファイルを送っていても、同じ公開鍵の再コピーで構いません。
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub管理ユーザーを作成して別接続で試す
サーバーで先にgetent passwd deployを実行します。何も返らないことを確認し、既存なら別の未使用名に統一してください。ホームパスやグループ名も含み、他人の鍵ファイルを置き換えないようにします。
OSとリソース、更新内容を確認して管理ユーザーを作ります。sudo用に強いパスワードを設定します。installコマンドは鍵ファイルの所有者と制限された権限を指定します。
cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keys手元の別ターミナルから新しい管理ユーザーで接続します。
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10新しいサーバー接続内でsudoを確認します。deployのパスワード入力後にrootと出れば成功です。この接続で続け、元のアクセスも残します。
sudo whoamiNginxと対応するファイアウォールを設定する
サーバーでNginxをインストールします。提供元とゲストOSの両方が通信を制限し得るため、コンソールと既存接続は開いたままにします。
sudo apt install nginx
sudo systemctl enable --now nginx提供元のネットワークでは管理元からTCP 22、訪問者からTCP 80/443を許可します。SSHが別ポートならその許可を保持します。提供元の許可だけでゲスト側の遮断は解除されません。
Oracle CloudのUbuntuイメージでは次のUFWブロック全体を飛ばします。UFWが重要なルールに干渉して起動を妨げる場合があります。iSCSIのブート／ブロック・ボリュームを守るiptablesも保持し、OCIのリストまたはNSGと、提供元の文書に沿うHTTP/HTTPSのゲストルールを使います。既存ルールの一括削除やパッケージ置換はしません。
ほかの新規Ubuntuで提供元がUFWを認め、別の管理済み設定を必要としない場合だけ、次を使います。有効化より前に実際のSSHポートを許可します。この例は22番です。
sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseどちらの方式でも新しいSSHログインを試します。既存の接続が残るだけでは確認になりません。証明書の前に、次節の外部HTTP確認も成功させます。
独立したNginxサイトとしてページを公開する
サーバーに新しい公開ディレクトリと設定を作ります。ホスト名を置き換え、EOFの引用符は残してください。$uriなどのNginx変数がシェルで展開されるのを防ぎます。
sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="ja"><title>初めての公開</title><h1>Ubuntu VPSからこのページを配信しています</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
listen 80;
listen [::]:80;
server_name app.example.com;
root /var/www/first-site;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -t設定テストが成功した場合だけ再読み込みします。
sudo systemctl reload nginxDNS変更前に手元からホスト名とIPを指定して確認します。Nginxの標準画面ではなく、自分の見出しが返ることを確かめます。
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/DNSを向けてHTTPS証明書を発行する
ドメインのAレコードをVPSのIPv4へ向けます。AAAAはそのサーバーでIPv6が動く場合だけ公開します。古いAAAAがあるとアクセスや証明書検証が別の宛先へ行く場合があります。この例はプロキシを挟まない直接DNSです。
手元で--resolveを使わずhttp://app.example.com/を開き、ページが返ってから続けます。サーバーではUbuntuのUniverseにあるCertbotとNginxプラグインを使います。パッケージが見つからなければリポジトリ設定を解決してから進めます。
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timerメールと規約の質問に答えます。Certbotはこのサイトの設定を編集してHTTPからHTTPSへ転送します。更新タイマーを確認し、停止中ならsudo systemctl enable --now certbot.timerで有効にします。HTTP認証と更新用に80番を到達可能に保ちます。
外部から確認し、再起動後にも試す
手元からリダイレクト、証明書、本文を確認します。HTTPはHTTPSへ転送され、HTTPSで見出しが表示される必要があります。証明書エラーを隠すcurlの-kは付けません。
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/まだ試験用の段階でサーバーにsudo rebootを実行します。復帰後にdeployで入り、systemctl is-active nginxと外部HTTPSを再確認します。SSHが切れるのは正常ですが、戻らなければコンソールを使います。
失敗を切り分け、再構築できる記録を残す
表を横にスクロールすると、残りの項目を確認できます。
| 症状 | 最初の確認 |
|---|---|
| SSHタイムアウト | IP、両方のファイアウォール、コンソール |
| 公開鍵の拒否 | ユーザー、秘密鍵、authorized_keysの権限 |
| Nginx標準画面 | DNS、server_name、有効なサイト |
| 証明書検証の失敗 | 公開A/AAAA、80番への到達 |
| 変更後のNginx停止 | sudo nginx -tとjournalctl -u nginx |
ログインできなければSSHの切り分けを使います。サイト、Nginx設定、DNS、構築メモをVPS外に保管し、ファイル復元を試します。TLS秘密鍵を保存するなら保護された保存先を使います。
全体の復旧には残りのアセット、証明書、サービス設定も必要です。稼働と証明書期限を監視し、1回の成功を将来の更新確認としないでください。DBやアプリを追加する場合は専用のサービス・バックアップ設定と負荷測定を行います。
よくある質問
既存サイトでそのまま実行できますか？
別の試験用VPSで始めてください。ファイル作成、通信設定、CertbotによるNginx編集を含むため、稼働中の構成と復旧方法を先に確認します。
WordPressやDBも入りますか？
この手順は静的HTTPSサイトです。アプリやデータベースは別途追加し、起動、動作確認、データ復旧を試します。
OracleでもUFWを使いますか？
使いません。この手順のOracle向け分岐に従い、イメージの重要なルールを保持します。
Ubuntu 24.04の新規VPS、直接DNS、SSH 22番を対象にした文書ベースの例です。提供元に合う通信設定を使ってください。全提供元のイメージで一連の操作を実証したものではありません。