【PR】この記事にはアフィリエイトリンク(ConoHa VPS・XServer VPS)が含まれます。
案件先や勤務先の都合で「サーバーは RHEL 系で」と言われることがあります。手元にあるのは Ubuntu で覚えた手順書。apt を叩いたら command not found、ufw も入っていない、そして極めつけが アプリは起動しているのにアクセスできない(実は SELinux が止めている)というやつです。
ただ、実際に並べてみると Ubuntu と AlmaLinux で本当に違うのは3点だけ でした。パッケージ管理(apt → dnf)、ファイアウォール(ufw → firewalld)、そして SELinux。systemd の使い方も、SSH 鍵認証の考え方も、作業ユーザーを作って root 常用をやめる流れも、ほとんどそのまま通用します。AlmaLinux VPSの初期設定は、この3点さえ読み替えれば Ubuntu の手順書がほぼそのまま通ります(あとは、イメージの初期状態がいくつか違うので確認コマンドで潰します)。
この記事は 「Ubuntu の初期設定を知っている人が、AlmaLinux で詰まる差分」だけ を扱います。役割分担はこうです。
- OS そのものの選び方(Debian 系 / RHEL 系のどちらにするか)→ VPSのOSはどれを選ぶ?
- どの VPS でも共通の「初期設定でやること」→ VPS初期設定のやることリスト
- Ubuntu でのコマンド通し手順 → Ubuntu 26.04 LTSのインストールと初期設定
- どの会社で契約するか → VPS比較2026
📌 この記事のコマンドは、AlmaLinux Wiki・firewalld・DNF/DNF5・OpenSSH 各プロジェクトの公式ドキュメントの記載(2026年8月19〜20日確認)をもとに整理したものです。筆者が日常的に運用しているのは ConoHa VPS 上の Ubuntu なので、AlmaLinux 側は「Ubuntu の手順をどう読み替えるか」という観点でまとめています。バージョンやイメージによって初期状態が違うことがあるため、各節に載せた確認コマンドを必ずセットで実行してください。
- ① パッケージ管理は
apt→dnf。apt updateに相当する明示的な操作は基本不要(dnf はキャッシュの期限を見て自動で取り直す)、履歴を巻き戻せるdnf history undoがある、自動セキュリティ更新はunattended-upgradesではなくdnf-automatic系。sudo を使えるグループはsudoではなくwheel - ② ファイアウォールは
ufw→firewalld。「ゾーン」という単位で管理し、--permanentを付けた変更は--reloadするまで効かない(付けないと再起動で消える)。ここが最大の「設定したつもり」ポイント - ③ SELinux が最初から有効。Ubuntu には無い仕組みで、権限が正しいのに拒否されるのはたいていこれ。無効化ではなく、ラベル・ブーリアン・ポートの3分岐で直すのが実務の作法
- 逆に言えば、それ以外(systemd・SSH鍵認証・ユーザー作成・ホスト名・日本語化・swap・タイムゾーン)はやることも考え方も Ubuntu と同じ。ただしイメージの初期状態が Ubuntu と違うので、次章の確認コマンドで先に現状を見ます
- AlmaLinux と Rocky Linux は、この3点に関してはどちらでも操作は同じ。選定で迷って手が止まるくらいなら先に進んでよい

AlmaLinux VPSの初期設定:Ubuntuと同じでいい部分・違う部分
初期設定で「やること」の並び自体は、Ubuntu でも AlmaLinux でも変わりません。パッケージを最新にして、作業ユーザーを作って、SSH 鍵認証にして、ファイアウォールを絞って、自動更新を仕込む。この並びは OS を問わず共通です。
違うのは ①コマンド(差分3点) と、②イメージの初期状態 の2つです。特に②は見落としやすく、「Ubuntu では最初から日本語ロケールが入っていたのに」「swap があるつもりでビルドを流したらメモリ不足で止まった」という形で後から刺さります。まずここを潰します。

Ubuntuと同じでいい部分(ただし初期状態は要確認)
以下は「Ubuntu でもやっていたこと」です。手順の意味は同じなので、コマンドと確認方法だけ載せます。
ホスト名を決める
# 現状確認
hostnamectl status
# 設定(例:alma-web01)
sudo hostnamectl set-hostname alma-web01
# 反映確認(Static hostname が変わっていること)
hostnamectl statushostnamectl は systemd のコマンドなので Ubuntu と同じです。VPS のコントロールパネル側で付けた名前と、OS 内部のホスト名は別物なので、両方合わせておくとログを追うときに混乱しません。
日本語ロケール(必要なら)
Ubuntu の日本語イメージと違い、AlmaLinux は英語ロケールで立ち上がることが多いです。日本語のメッセージが欲しい場合は言語パックを入れます。
# 現状確認(System Locale が LANG=C.UTF-8 などになっているはず)
localectl status
# 日本語の言語パックを入れる
sudo dnf install langpacks-ja glibc-langpack-ja
# ロケールを設定
sudo localectl set-locale LANG=ja_JP.UTF-8
# 反映確認(System Locale: LANG=ja_JP.UTF-8)
localectl status反映されるのはログインし直してからです。同じセッションで確認しようとして「変わっていない」と焦らないでください。なお、エラーメッセージを検索する頻度が高い人は、あえて英語のままにしておくほうが情報にたどり着きやすい場面もあります(後述の sealert の出力も、日本語になるのは日本語ロケールを入れた場合だけです)。
SWAP があるか確認する
VPS のイメージは swap が無い状態で配られることがよくあります。メモリ 1GB 前後のプランでビルドや dnf upgrade を流すと、swap が無いまま OOM で落ちます。
# swap があるか(何も出なければ無い)
swapon --show
free -h無ければ swap ファイルを作ります(例:2GB)。
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 再起動後も有効にする
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
# 反映確認
swapon --showここは AlmaLinux ならではの一手間があります。SELinux が有効なので、作ったファイルのラベルを既定に戻しておくと安全です。
sudo restorecon -v /swapfile
ls -Z /swapfile手順自体は Ubuntu と同じですが、restorecon のひと手間は Ubuntu には存在しません。SELinux まわりの考え方は後述の差分③で詳しく扱います。
タイムゾーン
# 現状確認
timedatectl
# 日本時間に
sudo timedatectl set-timezone Asia/Tokyo
# 反映確認(Time zone: Asia/Tokyo (JST, +0900))
timedatectlIPv6 と初期ユーザー
AlmaLinux の初期設定を検索すると「IPv6 を無効化する」という手順がよく出てきますが、まず使っているかどうかを見てからにしてください。
# IPv6 アドレスが付いているか
ip -6 addr
# 何がどのポートで待ち受けているか(:::22 のような表記が IPv6)
sudo ss -lntpsshd や Postfix が IPv6 でも待ち受けているだけなら、無効化する必要はありません。外から触られたくないなら、OS ごと無効化するより firewalld で閉じるほうが影響範囲が小さく、後から戻すのも簡単です。
初期ユーザーもイメージによって違います。AlmaLinux 公式のクラウドイメージには almalinux というユーザーが用意されていますが、VPS 事業者のイメージでは root で入る前提のことがあります(ConoHa VPS はこの形です)。まず現状を見てから、作業ユーザーを作るかどうかを決めます。
ls /home
getent passwd | tail -5ここから先が本題(違う3点)
ここまでは「同じことを、同じ意味でやる」だけでした。以降で扱う dnf・firewalld・SELinux の3点が、Ubuntu の手順書をそのまま流すと失敗する箇所です。
そもそも、なぜ今 AlmaLinux なのか
差分の話に入る前に、「なぜ RHEL 系の選択肢が AlmaLinux や Rocky Linux になったのか」を短く押さえておきます。バージョンの選び方とサポート期限の読み方が楽になります。
CentOS Linux の終了で何が起きたか
長らく「無料で使える RHEL 互換」の定番だった CentOS Linux は、CentOS Linux 8 が2021年12月31日、CentOS Linux 7 が2024年6月30日に End Of Life を迎えて終了しました(いずれも CentOS 公式のアナウンス)。
現在の CentOS Stream は RHEL の「上流」、つまり RHEL より先に新しいものが入る開発ラインです。「RHEL と同じものを後から無料で使う」という従来の使い方とは方向が逆になりました。そこで、RHEL 互換のリビルドとして登場したのが AlmaLinux と Rocky Linux です。VPS 各社の OS イメージ一覧にこの2つが並んでいるのは、この経緯によります。
Debian 系と RHEL 系のどちらを選ぶかという系統そのものの比較は VPSのOSはどれを選ぶ? の担当なので、そちらに譲ります。
AlmaLinux と Rocky Linux の違いは?初期設定に影響するか
よく聞かれるところなので、公式の表明ベースで整理します。
- 互換性の考え方が違う
-
Rocky Linux は公式サイトで「RHEL と 100% bug-for-bug 互換であることを目指す」と明言しています。一方 AlmaLinux は 2023年7月13日の公式ブログで、「1:1 を目指すのをやめ、バイナリ(ABI)互換を目指す」と方針転換を発表しました。RHEL 向けにビルドされたアプリがそのまま動くことは担保しつつ、Red Hat のリリースサイクル外の修正も取り込める、という立て付けです。
- 運営体が違う
-
AlmaLinux は AlmaLinux OS Foundation、Rocky Linux は Rocky Enterprise Software Foundation(RESF)が運営しています。どちらもコミュニティ財団型です。
- 対応 CPU の下限が違う(10系)
-
AlmaLinux 10.0 のリリースノートには、RHEL 10 が x86-64-v3 を前提にして古い CPU を切ったのに対し、AlmaLinux は古いハードウェア向けに x86-64-v2 のビルドも提供すると書かれています。VPS で借りる分には基本的に気にしなくてよい話ですが、手元の古い実機で検証したい場合には効いてきます。
サポート期限は AlmaLinux Wiki のリリースノートに記載があります(2026年8月19日確認)。
| バージョン | アクティブサポート | セキュリティサポート |
|---|---|---|
| AlmaLinux 8 | 2024年5月31日まで(終了) | 2029年5月31日まで |
| AlmaLinux 9 | 2027年5月31日まで | 2032年5月31日まで |
| AlmaLinux 10 | 2030年5月31日まで | 2035年5月31日まで |
新規に立てるなら 9系か10系 です。10系はリリースが新しい分、周辺ツールやミドルウェアの対応状況を先に確認しておくと安全です。案件で「既存サーバーと合わせて」と言われた場合はそれに従ってください。
そして本題ですが、この記事で扱う3点の差分は、AlmaLinux でも Rocky Linux でもまったく同じです。dnf・firewalld・SELinux は RHEL 系共通の仕組みだからです。どちらを選ぶかで悩んで手が止まっているなら、先に進んでしまってかまいません。
なお役割分担として、系統そのものの選び方(Debian 系か RHEL 系か)は 94 の記事が担当、この記事は「RHEL 系に決めた後の読み替え」が担当です。まだ決めきれていない場合は先にそちらを読んでください。

差分①:パッケージ管理が apt から dnf に変わる
いちばん最初にぶつかるのがこれです。apt は入っていません。RHEL 系のパッケージ管理は dnf(RPM パッケージを扱うフロントエンド)です。
apt → dnf コマンド対応表
Ubuntu の手順書を読み替えるときは、この表を横に置いておけばだいたい足ります。
| やりたいこと | Ubuntu(apt) | AlmaLinux(dnf) |
|---|---|---|
| パッケージ情報の更新 | sudo apt update | 基本は不要(キャッシュの期限切れ時に自動更新。明示するなら sudo dnf makecache --refresh) |
| 更新があるか確認 | apt list --upgradable | dnf check-update(更新があると終了コード 100) |
| 全体を更新 | sudo apt upgrade | sudo dnf upgrade |
| セキュリティ更新のみ | (標準では分離できない) | sudo dnf upgrade --security |
| インストール | sudo apt install nginx | sudo dnf install nginx |
| アンインストール | sudo apt remove nginx | sudo dnf remove nginx |
| 不要な依存を掃除 | sudo apt autoremove | sudo dnf autoremove |
| 検索 | apt search キーワード | dnf search キーワード |
| このコマンドはどのパッケージ? | apt-file search /usr/bin/foo(apt-file は別途インストール) | dnf provides '*/foo'(クォート必須) |
| インストール済み一覧 | dpkg -l | rpm -qa |
| パッケージが入れたファイル一覧 | dpkg -L nginx | rpm -ql nginx |
| リポジトリ一覧 | apt-cache policy | dnf repolist |
| リポジトリ追加 | sudo add-apt-repository ... | /etc/yum.repos.d/*.repo を置く(dnf config-manager) |
| 直前の操作を取り消す | (標準では困難) | sudo dnf history → sudo dnf history undo <ID> |
| 再起動が必要か確認 | needrestart | 9系:needs-restarting -r(sudo dnf install yum-utils)/10系:dnf needs-restarting |
読み替えのポイントは3つです。
1. apt update に当たる操作が基本は要らない。 dnf はメタデータをキャッシュしていて、metadata_expire(既定48時間・リポジトリ側で上書きあり)が切れていれば自動で取り直します。つまり sudo dnf install ○○ だけでもだいたい足りますが、最大で48時間古い情報を使うことがあるという点は覚えておいてください。確実に最新にしたいときは --refresh を付けます。
# 手順書に apt update && apt upgrade と書いてあったらこれ
sudo dnf upgrade --refresh2. セキュリティ更新だけを当てられる。 dnf upgrade --security は、アドバイザリ(errata)情報をもとに「セキュリティ修正だけ」を選んで適用します。AlmaLinux はセキュリティアドバイザリ(ALSA)を公開するサイトを運営しているので、本番サーバーで「機能追加は避けたいがセキュリティ修正は当てたい」という運用と相性が良いです。適用対象を先に一覧したいときは、dnf のメジャーバージョンでサブコマンドが違います。
# 9系(DNF4)
dnf updateinfo list security
# 10系(DNF5):updateinfo は互換エイリアスとして残るが advisory が正式
dnf advisory list --security3. 操作を巻き戻せる。 dnf history でトランザクション単位の履歴が残り、dnf history undo <ID> でその操作を戻せます。apt に慣れているとつい忘れますが、更新でアプリが動かなくなったときの逃げ道として覚えておく価値があります。
ハマりどころ:needs-restarting は「dnf のサブコマンド」ではない(9系)
再起動が必要かを判定する needs-restarting は、9系(DNF4)では dnf のサブコマンドではありません。yum-utils(=dnf-utils)が入れる単体コマンドなので、dnf needs-restarting -r と打つと「そんなコマンドは無い」と言われます。
# 9系(DNF4):単体コマンド。まずインストールが必要
sudo dnf install yum-utils
needs-restarting -r
# 10系(DNF5):dnf のサブコマンドになった
dnf needs-restartingどのパッケージが提供しているか分からなくなったら、dnf provides で引けます(ワイルドカードはクォートで囲む。囲まないとシェルがカレントディレクトリで展開してしまいます)。
dnf provides '*/needs-restarting'パッケージ名そのものが違うものリスト
コマンドを読み替えても、パッケージ名が違って詰まることがよくあります。よく使うものだけ挙げておきます。
| 用途 | Ubuntu | AlmaLinux |
|---|---|---|
| Apache HTTP Server | apache2(サービス名も apache2) | httpd(サービス名も httpd) |
| ファイアウォール | ufw | firewalld |
| 自動セキュリティ更新 | unattended-upgrades | dnf-automatic 系(後述) |
| ネットワーク設定 | netplan | NetworkManager(nmcli) |
| sudo を許可するグループ | sudo グループ | wheel グループ |
| アクセス制御(MAC) | 既定は AppArmor | SELinux(policycoreutils-python-utils ほか) |
リポジトリの考え方(/etc/apt/sources.list → /etc/yum.repos.d/)
追加リポジトリの置き場所も違います。Ubuntu の /etc/apt/sources.list や sources.list.d/ に当たるのが /etc/yum.repos.d/*.repo です。現状は dnf repolist で確認できます。
RHEL 系では、標準リポジトリに無いパッケージを EPEL(Extra Packages for Enterprise Linux)から入れる場面がよくあります。また、開発用パッケージが入っている CRB(AlmaLinux 9系。8系では PowerTools)というリポジトリは、9系では既定で無効です。
まず、config-manager 自体が入っていないことがあります。minimal 系のイメージだと No such command: config-manager になるので、先に入れておきます。
# 9系(DNF4)で config-manager が無い場合
sudo dnf install dnf-plugins-core
# CRB を有効化(AlmaLinux Wiki の記載どおり。8系は powertools)
sudo dnf config-manager --set-enabled crb
# 反映確認(crb の行が出ること)
dnf repolist | grep -i crb10系(DNF5)は書式が違います。 --set-enabled は DNF5 で廃止され、setopt に変わりました。設定は 99-config_manager.repo という上書き用ファイルに書かれ、元の .repo は変更されません。
# 10系(DNF5)
sudo dnf config-manager setopt crb.enabled=1なお AlmaLinux は 2025年9月の公式ブログで、AlmaLinux 10 では CRB を既定で有効にする方針を発表しています。10系では最初から有効になっていることがあるので、まず dnf repolist で現状を見てください。EPEL の導入手順は、EPEL 公式ドキュメントの該当バージョンの記載に従います。
ハマりどころ:adduser が「何も聞かずに」終わる
Ubuntu の adduser は対話式で、パスワードやフルネームを聞いてくれる便利スクリプトでした。RHEL 系の adduser は useradd と同じもので、対話は一切ありません。何も聞かれずにプロンプトが返ってくるので「失敗した?」と戸惑いますが、ユーザーはできています。ただし パスワードが設定されていないので、続けて passwd を実行する必要があります。
そして sudo 権限を与えるグループは wheel です。sudo グループを指定しても存在しないか、存在しても sudoers で許可されていません。
# 作業用ユーザーを作る(対話は無い)
sudo useradd michi
sudo passwd michi
# sudo が使えるグループは wheel(Ubuntu の sudo グループに相当)
sudo usermod -aG wheel michi反映の確認は、実際にそのユーザーで sudo が通るかを見るのが確実です。
# 所属グループの確認
id michi
# 作業ユーザーに切り替えて sudo が通るか試す
su - michi
sudo -lsudo -l で (ALL) ALL のような許可行が出れば成功です。ここを確認せずに root ログインを止めると、誰も管理操作ができないサーバーができあがります(Ubuntu でも同じですが、グループ名が違う分ここで踏みやすい)。
自動セキュリティ更新は dnf-automatic 系に読み替える
Ubuntu の unattended-upgrades に当たるのが dnf 側の automatic プラグインです。9系と10系で名前が変わっているので、まず自分の環境がどちらかを確認します。
dnf --version
dnf search automatic出力に応じて、次のように読み替えます(いずれも DNF / DNF5 プロジェクト公式ドキュメントの記載)。
| パッケージ名 | systemd タイマー | 設定ファイル | |
|---|---|---|---|
| DNF 4 系(9系で一般的) | dnf-automatic | dnf-automatic.timer | /etc/dnf/automatic.conf |
| DNF 5 系(10系で採用) | dnf5-plugin-automatic | dnf5-automatic.timer | /etc/dnf/automatic.conf |
設定ファイルの要点はどちらも同じで、「セキュリティ更新だけを、ダウンロードだけでなく適用まで行う」なら次の2項目を変更します。
# /etc/dnf/automatic.conf
[commands]
upgrade_type = security
apply_updates = yes有効化と確認(DNF 4 系の例。10系ではタイマー名を dnf5-automatic.timer に読み替え)。
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
# 反映確認:タイマーが有効で、次回実行予定が入っているか
systemctl list-timers 'dnf*'
systemctl status dnf-automatic.timerenable --now を付け忘れて「インストールしただけ」になっているケースが定番です。systemctl list-timers に行が出てこなければ動いていません。
差分②:ファイアウォールが ufw から firewalld に変わる
Ubuntu で ufw allow OpenSSH → ufw enable の2行で済ませていた部分が、AlmaLinux では firewalld になります。コマンドが違うだけでなく、考え方(ゾーン)と反映のしかた(permanent と runtime)が違うので、ここは丁寧に押さえます。
「ゾーン」は接続先ネットワークの信用度ラベル
firewalld は、ネットワークインターフェースや送信元 IP を ゾーン に割り当て、ゾーンごとに「何を通すか」を決めます。公式ドキュメントに載っている定義済みゾーンは、信用度の低い順に drop / block / public / external / dmz / work / home / internal / trusted の9つです。ただし実機で firewall-cmd --get-zones を叩くと、NetworkManager が接続共有用に使う nm-shared が加わって10個返ってくることがあります。数が合わなくても壊れているわけではないので、実際の一覧はコマンドで確認してください。
VPS で使うのはほぼ public ひとつだけです。公式ドキュメントの説明は「公共の場で使うためのゾーン。他のコンピュータを信用せず、選択した着信接続だけを受け入れる」。つまり Ubuntu の ufw で「必要な穴だけ開ける」のと同じ発想です。
まず現状確認から始めます。イメージによっては firewalld 自体が入っていないことがあるので、存在確認から入ります。
# そもそも入っているか(入っていなければ sudo dnf install firewalld)
rpm -q firewalld
# firewalld が動いているか
systemctl status firewalld
# ゾーンの一覧と既定ゾーン(通常 public)
sudo firewall-cmd --get-zones
sudo firewall-cmd --get-default-zone
# そのゾーンで今何が許可されているか(いちばん見る画面)
sudo firewall-cmd --list-all--list-all の services: 行に ssh が入っていれば、SSH は既に通っています。この時点で 「ufw と違って最初から何かが許可されている」ことに気づけるかどうかが分かれ目です。
ufw → firewalld コマンド対応表
| やりたいこと | ufw | firewalld |
|---|---|---|
| 有効化 | sudo ufw enable | sudo systemctl enable --now firewalld |
| 現状確認 | sudo ufw status verbose | sudo firewall-cmd --list-all |
| SSH を許可 | sudo ufw allow OpenSSH | sudo firewall-cmd --permanent --add-service=ssh |
| HTTP/HTTPS を許可 | sudo ufw allow 80,443/tcp | sudo firewall-cmd --permanent --add-service=http --add-service=https |
| 任意のポートを許可 | sudo ufw allow 8080/tcp | sudo firewall-cmd --permanent --add-port=8080/tcp |
| 許可を取り消す | sudo ufw delete allow 80/tcp | sudo firewall-cmd --permanent --remove-service=http |
| 設定を反映 | (即時反映) | sudo firewall-cmd --reload |
| 送信元 IP を絞る | sudo ufw allow from 203.0.113.5 to any port 22 | リッチルール(下記) |
| 使えるサービス名一覧 | (なし) | firewall-cmd --get-services |
送信元 IP を絞る例(自宅の固定 IP からだけ SSH を許可する形)。
# 203.0.113.5 からの SSH だけ許可する
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.5/32" service name="ssh" accept'
# 誰からでも入れる ssh 許可を外す
sudo firewall-cmd --permanent --remove-service=ssh
# 反映
sudo firewall-cmd --reload
sudo firewall-cmd --list-all⚠️ この操作は自分を締め出す典型パターンです。今つないでいるセッションは残るので、別のターミナルを開いて新規接続できることを確認するまで、今のセッションを閉じないでください。回線が変わる(自宅の IP が変わる・モバイル回線に切り替える)と入れなくなる点も含めて、VPS のコンソール機能で入り直せることを先に確認しておくと安全です。
ハマりどころ:--permanent と --reload の二重構造
firewalld には runtime(今動いている設定) と permanent(再起動後も残る設定) の2つがあり、これが独立しています。公式マニュアルの表現では、--permanent を付けた変更は「即座には有効にならず、サービスの再起動・リロード後に有効になる」、そして --reload は「permanent の設定を新しい runtime 設定にする」です。
つまり、こうなります。
--permanentを付けない → すぐ効くが、再起動やリロードで消える--permanentを付ける → 残るが、--reloadするまで効かない
「設定したのに繋がらない」「昨日は動いていたのに再起動したら塞がった」の大半はこれです。必ず --permanent を付けて、最後に --reload、そして --list-all で目視確認 の3点セットで運用してください。
なお、runtime でその場しのぎに開けた設定を永続化したいときは、次のコマンドでまとめて写せます。
# 今動いている設定を permanent に書き出す
sudo firewall-cmd --runtime-to-permanentVPS 側のファイアウォールとの二段構え
ConoHa VPS のセキュリティグループのように、VPS 事業者側にも別のファイアウォールがあります。サーバー内の firewalld で開けても、その手前で閉じていれば通りません。この二段構えの考え方と、事業者側のコントロールパネルでの絞り方は、下の関連記事にまとめてあります(ufw か firewalld かに関係なく共通の話です)。

差分③:SELinux が最初から有効になっている
3つ目にして最大の関門です。Ubuntu には無い(Ubuntu は既定で AppArmor を使う)ので、初見だと 「パーミッションは正しいのに読めない」「ポートを開けたのにサービスが起動しない」 という不可解な現象として現れます。
SELinux は「プロセスにできることを型で縛る」仕組み
通常の Linux のパーミッション(所有者・グループ・rwx)とは別のレイヤーで、「このプロセスは、この型のファイルにしか触れない」「このサービスは、この番号のポートしか使えない」という制限をかけるのが SELinux です。ファイルやポートには ラベル(型) が付いていて、ls -Z や semanage port -l で見られます。
だから、chmod 777 にしても直りません。パーミッションの問題ではないからです。ここを理解しないまま検索すると、まっさきに「SELinux を無効化する」という記事に当たります。
それでも無効化を勧めない理由
無効化すればその場は動きます。ですが、
- 本番で効いていた防御を、原因を特定しないまま全部外すことになる(1つのアプリの問題で、サーバー全体の保護を落とす)
- 案件・受託の環境では、SELinux 有効が前提条件になっていることがある(あとで戻すときに大量の設定不足が一気に噴出する)
- 実際の対処は、たいていコマンド1〜2行で済む
からです。以下の切り分けを覚えてしまったほうが、長い目で見て速いです。

まず状態を確認する
# 一言で確認(Enforcing / Permissive / Disabled)
getenforce
# 詳しく確認(現在のモードと設定ファイル上のモード、ポリシー名)
sestatusEnforcing なら、ルール違反は実際にブロックされます。Permissive はログだけ出して通す状態です。イメージによって初期状態が違うことがあるので、手順書を書く前にここを見るのが鉄則です。
詰まったら、まず拒否ログを読む
「動かない」と感じたら、推測せずログを見ます。AVC(Access Vector Cache)という拒否ログが記録されています。
# 前提:監査デーモンが動いていること(止まっているとログが空振りする)
systemctl is-active auditd
# 直近(およそ10分以内)の拒否ログを見る
sudo ausearch -m AVC,USER_AVC -ts recent
# auditd を使っていない環境ではこちらでも拾える
sudo journalctl -t setroubleshootより読みやすい説明が欲しいときは sealert を使います。
sudo dnf install setroubleshoot-server
sudo sealert -a /var/log/audit/audit.logsealert は「何が・何に対して・どの操作を拒否されたか」と、対処コマンドの候補まで出してくれます(出力の言語はロケール依存で、既定の英語ロケールのままなら英語です)。ただし 提案されたコマンドを読まずに実行しないでください(audit2allow 系は、内容によっては穴を大きく開けます)。
以降の操作には semanage が必要です。入っていなければ追加します。
sudo dnf install policycoreutils-python-utils原因は「ラベル」「ブーリアン」「ポート」のどれか
実務で当たるものは、ほぼこの3種類です。
① ラベル(ファイルの置き場所が標準外)
/var/www/html ではなく /srv/www に Web コンテンツを置いた、といったケース。ファイルに付いた型が Web サーバー用でないため読めません。
# 今のラベルを確認
ls -Z /srv/www
# 「このパス以下は Web コンテンツ型」というルールを登録し、実ファイルに適用
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"
sudo restorecon -Rv /srv/www
# 反映確認(型が httpd_sys_content_t になっていること)
ls -Z /srv/wwwrestorecon を忘れるとルールは登録されたのにファイルのラベルは古いままで、症状が変わりません。semanage fcontext と restorecon は必ずセットです。
② ブーリアン(機能が既定でオフ)
「Web サーバーから外部に接続する」「Web サーバーがユーザーのホームディレクトリを読む」といった動作は、既定で禁止されているものがあります。オン・オフのスイッチが ブーリアン です。
# 関係しそうなスイッチを探す
getsebool -a | grep httpd
# 例:httpd から外部への接続を許可(-P で再起動後も維持)
sudo setsebool -P httpd_can_network_connect on
# 反映確認
getsebool httpd_can_network_connect-P を付け忘れると再起動で元に戻ります。これも「設定したのに素通し」の典型です。
③ ポート(標準以外の番号を使う)
サービスが使ってよいポート番号も型で決まっています。標準外の番号で待ち受けるときは、その番号を型に登録します。先に「その番号が既に別の型で使われていないか」を見るのがコツです。
# その番号が既に登録されていないか確認
sudo semanage port -l | grep -w 2222
# 何も出なければ新規追加(-a)
sudo semanage port -a -t ssh_port_t -p tcp 2222
# 別の型で既に出ていた場合は変更(-m)に読み替える
# sudo semanage port -m -t ssh_port_t -p tcp 2222
# 反映確認
sudo semanage port -l | grep ssh_port_t-a のまま実行して ValueError: Port tcp/2222 already defined が出たら、それは「もう登録済み」というサインです。手順をやり直しているときにも出るので、慌てず -l で現状を見てください。
「sshd_config を書き換えて再起動したら sshd が起動しなくなった」という現象は、たいていこのポート登録漏れが原因です。次章で通しの手順にまとめます。
一時的に切り分けたいとき(調査のときだけ)
「本当に SELinux が原因か」を確かめたいときだけ、一時的に Permissive にして挙動を見る方法があります。確認したらすぐ戻すのが前提です。
# 一時的に Permissive(再起動すると元に戻る)
sudo setenforce 0
# 動くかどうか確認したら、必ず戻す
sudo setenforce 1
getenforcePermissive にして動いたなら「SELinux が原因」と確定しただけで、解決はしていません。上の3分岐で直してから Enforcing に戻してください。/etc/selinux/config を書き換えて恒久的に無効化する方法もありますが、この記事では勧めません(無効化が本当に必要な事情がある場合は、影響範囲と手順を AlmaLinux / Red Hat の公式ドキュメントで確認してから判断してください)。
実践:AlmaLinux VPSの初期設定でSSHポートを22番から変える(3ステップ)
差分3点が全部関わる、いちばん分かりやすい例がこれです。sshd の設定・SELinux のポート登録・firewalld の開放が、そのまま3ステップになります。前後に「準備(作業ユーザーの鍵を置く)」と「仕上げ(22番を閉じる)」が付きます。
Ubuntu との違いはここです。
- Ubuntu 22.10〜23.10:sshd がソケット起動になったため、
sshd_configのPortは使われない。systemctl edit ssh.socketでListenStreamを変更する - Ubuntu 24.04 以降:
sshd-socket-generatorがsshd_configを読んでssh.socketのドロップインを生成するので、Portの指定でも反映される(systemctl cat ssh.socketで生成結果を確認できる) - AlmaLinux:sshd はソケット起動ではないので設定ファイルで変える。ただし SELinux のポート登録と firewalld の開放が追加で必要

準備:作業ユーザーに公開鍵を置く(ここを飛ばすと締め出されます)
ConoHa VPS のように root +鍵認証で初回接続するイメージでは、作業ユーザー(例:michi)にはまだ鍵がありません。この状態で後述の PasswordAuthentication no と PermitRootLogin no を適用すると、root は禁止・作業ユーザーは鍵が無い・パスワードも不可となり、コンソール救済コースに直行します。
先に鍵を置きます。ローカルから ssh-copy-id を使ってもよいですし、root で入っているならコピーでも構いません。
sudo mkdir -p /home/michi/.ssh && sudo chmod 700 /home/michi/.ssh
sudo cp /root/.ssh/authorized_keys /home/michi/.ssh/
sudo chown -R michi:michi /home/michi/.ssh
sudo chmod 600 /home/michi/.ssh/authorized_keys
# AlmaLinux ではここが必須:SELinux のラベルを付け直す
sudo restorecon -Rv /home/michi/.ssh
# 反映確認(ssh_home_t になっていること)
ls -Z /home/michi/.sshrestorecon を忘れると、パーミッションが正しくても鍵認証だけ失敗します。 root が /home/michi/.ssh を手作りするとラベルが ssh_home_t にならないためで、Ubuntu には無いハマりどころです。パーミッションを何度見直しても直らないときは、まず ls -Z を疑ってください。
そのうえで、別のターミナルから ssh michi@サーバーのIP で鍵ログインが成功することを確認するまで、次のステップに進まないでください。
下準備:ドロップインが読まれるか確認する
RHEL 系の多くのイメージでは、/etc/ssh/sshd_config の冒頭に Include /etc/ssh/sshd_config.d/*.conf があり、ドロップインファイルで設定を上書きできます。まず本当に Include されているか、そして既に何が置かれているかを確認します。
grep -n '^Include' /etc/ssh/sshd_config
ls -l /etc/ssh/sshd_config.d/Include 行があるなら、/etc/ssh/sshd_config.d/ にファイルを置きます。このとき、ファイル名の数字が重要です。sshd は同じ項目について原則最初に見つかった値を採用するため、ディストリ側が最初から置いているファイルより若い番号にしないと、自分の設定が負けます。Ubuntu で 50-cloud-init.conf に負けるのと同じ構図です(Ubuntu 26.04 LTSのインストールと初期設定 で扱ったハマりどころ)。
そして AlmaLinux 9 のクラウドイメージには、/etc/ssh/sshd_config.d/01-permitrootlogin.conf(中身は PermitRootLogin yes)が最初から置かれていることがあります。番号が 01 なので、50-redhat.conf だけを想定して 49- などのファイルを作ると負けます。「sshd_config 本体を直したのに PermitRootLogin が yes のままだ」という現象の犯人はたいていこれです。必ず上の ls -l で現物を確認してください(この記事では 00- で始まる名前を使うので、01- にも 50- にも先んじます)。
Include 行が無い(8系など)場合は、/etc/ssh/sshd_config 本体を編集してください。
ステップ1:sshd の設定を書く
sudo vi /etc/ssh/sshd_config.d/00-hardening.conf# SSH の待ち受けポート
Port 2222
# rootでの直接ログインを禁止
PermitRootLogin no
# パスワード認証を禁止(鍵認証のみ)
PasswordAuthentication no
PubkeyAuthentication yes⚠️
Portだけは「最初の値が勝つ」の例外です。 sshd_config のマニュアルは “Unless noted otherwise, for each keyword, the first obtained value will be used”(特に断りが無ければ最初の値を使う)と書いており、Portはその例外で “Multiple options of this type are permitted.”=複数指定は上書きではなく追加になります。本体や他のドロップインにPort 22が生きていれば、22番と2222番の両方で待ち受けます。残っていないか先に確認してください。
grep -rn '^[[:space:]]*Port' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/この時点ではまだ再起動しないでください。 SELinux とファイアウォールを先に通します。
ステップ2:SELinux にポートを登録する(Ubuntuには無い手順)
sudo semanage port -l | grep -w 2222
sudo semanage port -a -t ssh_port_t -p tcp 2222
sudo semanage port -l | grep ssh_port_tこれを飛ばすと、sshd の再起動時に「そのポートでは待ち受けられない」と拒否され、サービスが起動に失敗します。慌てて sshd_config を疑い続けることになるので、順番として先にやっておくのが安全です。
ステップ3:firewalld で新しいポートを開ける
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-allVPS 事業者側のファイアウォール(ConoHa VPS ならセキュリティグループ)を使っている場合は、そちらでも 2222 番の許可が必要です。片方だけだと通りません。
反映確認:sshd -T で「実際に効いている値」を見る
設定ファイルを書いただけ、再起動しただけでは確認になりません。sshd が最終的に採用した値を直接見ます。
sudo sshd -T | grep -Ei '^port|permitrootlogin|passwordauthentication'port 2222
permitrootlogin no
passwordauthentication noport の行が 2222 の1行だけであることが重要です。もし port 22 も並んで出ているなら、どこかに Port 22 が残っていて 22番が開いたままになっています(上の grep -rn で犯人を探してください)。port 22 しか出ない場合は、ファイル名の番号が負けているか、Include が無いかのどちらかです。
確認できたら再起動します。
sudo systemctl restart sshd
sudo systemctl status sshd⚠️ 今つないでいるセッションは閉じないでください。 別のターミナルから
ssh -p 2222 michi@サーバーのIPで入れることを確認してから、元のセッションを終了します。締め出された場合の最後の砦は VPS 事業者のコンソール機能です。ポート変更は「安全になる」というより「自動スキャンとログのノイズが減る」施策なので、自信が無いうちは 22 番のまま鍵認証だけにしておく判断も十分ありです。
仕上げ:22番の穴を塞ぐ
ここまでで 2222 番が開きましたが、既定ゾーンの ssh サービス(22/tcp)は開いたままです。この状態では「スキャンとログのノイズを減らす」という目的が達成できません。2222 番で入れることを確認してから、22番を閉じます。
# 2222 番でログインできることを別ターミナルで確認してから実行する
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload
# 反映確認:services に ssh が無く、ports に 2222/tcp があること
sudo firewall-cmd --list-all順番を逆にすると(22番を閉じてから 2222 の疎通確認をすると)、そのまま入れなくなります。「開けて・確認して・閉じる」 の順を守ってください。

AlmaLinux イメージを提供している VPS(当サイト提携の2社)
AlmaLinux を選ぶ場合、OS イメージとして提供されているかとどのバージョンが選べるかは会社によって違います。ここでは当サイトが提携している2社について、公式ページで確認できた内容だけを載せます(2026年8月19日時点。提供バージョンは随時追加・終了するので、申し込み前に必ず公式でご確認ください)。他社にも AlmaLinux を提供しているところはありますが、提携していない会社にはリンクを張らない方針のため、ここでは扱いません。
ConoHa VPS
公式ドキュメントの AlmaLinux イメージのページには、提供バージョンとして 10.2 / 10.1 / 10.0 / 9.8 / 9.7 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 8.10 / 8.9 / 8.8 が挙げられています。最新の 10.2 系まで揃っているので、新規に9系・10系どちらで立てたい場合も選べます。
同ドキュメントでは、作成直後の接続は root ユーザー+鍵認証(ssh -i 秘密鍵ファイルのパス root@VPSのグローバルIPアドレス)と案内されています。つまり最初は root で入る前提なので、この記事の「作業ユーザーを作って wheel に入れる → 鍵をコピーして restorecon → root ログインを止める」の順番がそのまま当てはまります。
筆者がこのサイト周辺の検証環境で使っているのも ConoHa VPS ですが、載せているのは Ubuntu です(AlmaLinux での常用実績はありません)。料金体系が時間単位の課金なので、「AlmaLinux を短時間だけ立てて手順を試して消す」という使い方とは、仕組みのうえで相性が良いはずです。単価は公式の料金ページでご確認ください。
【PR】以下は ConoHa VPS の広告リンクです。料金・提供イメージ・キャンペーンの適用条件は必ず公式サイトでご確認ください。
XServer VPS
公式の「OS・アプリイメージ一覧」ページでは、AlmaLinux として 8.6/8.7/8.8/8.9/8.10/9.0〜9.8/10.0/10.1/10.2(いずれも64bit) が掲載されています。Rocky Linux も同じ範囲のバージョンが並んでいます(2026年8月19日時点)。案件で細かいマイナーバージョンを指定されたときは、この一覧に該当するものがあるかを先に見ておくと確実です。
なお筆者は XServer VPS を実運用していないため、ここは公式サイトの表記に基づく紹介にとどめます。会社ごとの料金・課金方式の比較は別記事にまとめてあります。
【PR】以下は XServer VPS の広告リンクです。プランの受付状況・提供イメージ・料金は必ず公式サイトでご確認ください。

ちなみに、開発・検証用の VPS 代のうち 事業で使う分は必要経費に計上できます(私用と兼ねる場合は按分が必要です。判断は国税庁の情報や税理士にご確認ください)。仕訳や勘定科目の考え方は サーバー代の勘定科目と経費計上 にまとめました。金額としては小さくても年間では積み上がるので、手取りへの影響を一度ざっくり見ておくと、スペックを1段上げる判断がしやすくなります。サーバー構築を受託する場合の見積もりは 見積もりジェネレータ で作れます。
Ubuntu に戻るべき? AlmaLinux を続けるべき?
ここまでの差分を踏まえた、率直な線引きです。
- 案件・勤務先・既存サーバーが RHEL 系 → 迷わず AlmaLinux(または Rocky Linux)。手順書やミドルウェアの前提が RHEL 系で書かれているので、揃えたほうが結果的に速い
- 自分ひとりの環境で、参考にする日本語記事が Ubuntu 前提ばかり → 無理に RHEL 系にしなくてよい。ネット上の情報量は Ubuntu 系のほうが厚い
- RHEL 系の運用経験そのものを増やしたい → AlmaLinux は良い教材。特に SELinux は、触っておくと「サーバーが動かない理由」の引き出しが1つ増える
どちらの系統を選ぶかという話は VPSのOSはどれを選ぶ? で扱っているので、まだ決めきれていない場合はそちらを先に読んでください。Ubuntu 側の言い分は Ubuntu VPSを初心者に勧める理由 に整理してあります。この記事は「RHEL 系でいく」と決めた後の読み替え表という位置づけです。
AlmaLinux VPSの初期設定でよくある質問
- AlmaLinux と Rocky Linux、初期設定のやり方は違いますか?
-
この記事で扱った3点(dnf・firewalld・SELinux)については同じです。どちらも RHEL 互換のディストリビューションで、パッケージ管理もファイアウォールもアクセス制御の仕組みも共通だからです。違いは互換性の方針(Rocky は「bug-for-bug 互換」、AlmaLinux は 2023年7月に「ABI 互換」へ方針転換)や運営体、10系での対応 CPU の下限などで、日常のコマンド操作にはほとんど影響しません。
- SELinux は無効化してしまってもいいですか?
-
おすすめしません。動かない原因のほとんどは「ファイルのラベル」「ブーリアン(機能スイッチ)」「ポートの登録」のどれかで、いずれもコマンド1〜2行で解決できます。無効化は、原因を特定しないままサーバー全体の防御を外す対応になります。まず
sudo ausearch -m AVC,USER_AVC -ts recentで拒否ログを確認し、該当する分岐で直してください。切り分けのためにsetenforce 0を使う場合も、確認後にsetenforce 1で必ず戻します。 - Ubuntu 向けに書かれた手順書はそのまま使えますか?
-
コマンド名を読み替えれば大半は使えます。置き換えが必要になるのは、パッケージ管理(
apt→dnf)、パッケージ名(例:apache2→httpd)、sudo 用グループ(sudo→wheel)、ファイアウォール(ufw→firewalld)、そして SELinux 関連の追加作業です。特に「ポート番号を変える」系の手順は、AlmaLinux では SELinux へのポート登録(semanage port -a)が追加で必要になるので、そのまま実行すると sshd の起動に失敗します。ホームディレクトリに.sshを手作りしたときのrestoreconも、Ubuntu の手順書には出てこない項目です。 - AlmaLinux 8 を今から新規に使ってもいいですか?
-
新規なら9系か10系を選ぶのが無難です。AlmaLinux Wiki の記載(2026年8月19日確認)では、8系はアクティブサポートが2024年5月31日で終了し、セキュリティサポートが2029年5月31日まで。9系はセキュリティサポートが2032年5月31日まで、10系は2035年5月31日までとなっています。既存サーバーとバージョンを揃える必要がある場合を除き、サポート期間の長いほうを選んでおくと後の移行が減ります。
まとめ:AlmaLinux VPSの初期設定は、3点の読み替えで足りる
AlmaLinux(RHEL 系)の初期設定でつまずくポイントを、もう一度整理します。
1. パッケージ管理:apt → dnf。apt update 相当は基本不要(キャッシュ期限は既定48時間)、dnf history undo で巻き戻せる、自動更新は dnf-automatic 系、sudo は wheel グループ 2. ファイアウォール:ufw → firewalld。ゾーン(VPS では public)で管理し、--permanent を付けたら --reload、最後に --list-all で目視確認 3. SELinux:無効化せず、ausearch で拒否ログを読んで ラベル・ブーリアン・ポート の3分岐で直す
そのうえで、イメージの初期状態(ホスト名・日本語ロケール・swap・タイムゾーン)は Ubuntu と違うことがあるので、hostnamectl status / localectl status / swapon --show / timedatectl で先に現状を見るのが確実です。
そして共通する作法として、「設定を書いた」で終わらせず、必ず反映確認コマンドをセットで実行すること。sshd -T、firewall-cmd --list-all、getenforce、systemctl list-timers の4つは、AlmaLinux でも Ubuntu でも同じくらい役に立ちます。
初期設定そのものの全体像(何をどの順でやるか)は VPS初期設定のやることリスト、Ubuntu でのコマンド通し手順は Ubuntu 26.04 LTSのインストールと初期設定 にまとめてあります。RHEL 系で立てたサーバーでも、やること自体の並びは変わりません。

読むだけで身につく分野ではないので、AlmaLinux を1台立てて、この記事の3点を実際に叩いてみるのが結局いちばん速いです。時間単位で課金されるサービスなら、短時間の検証で費用を抑えられます(料金体系・単価は各社・プランで異なるため、必ず公式でご確認ください)。
【PR】以下は ConoHa VPS の広告リンクです。料金・提供イメージは申し込み前に必ず公式サイトでご確認ください。
ConoHa VPS の AlmaLinux イメージと料金を公式サイトで確認する—
出典(すべて2026年8月19〜20日に確認)
- AlmaLinux OS 公式サイト:https://almalinux.org/
- AlmaLinux Wiki リリースノート(各バージョンのサポート期限):https://wiki.almalinux.org/release-notes/
- AlmaLinux 10.0 リリースノート(x86-64-v2 の提供・32bitパッケージ廃止):https://wiki.almalinux.org/release-notes/10.0.html
- AlmaLinux 公式ブログ「The Future of AlmaLinux is Bright」(2023年7月13日・ABI互換への方針転換):https://almalinux.org/blog/future-of-almalinux/
- AlmaLinux 公式ブログ「Enabling CRB by default for AlmaLinux 10」(2025年9月・10系でCRBを既定有効化):https://almalinux.org/blog/2025-09-08-enabling-crb-by-default-for-almalinux10/
- AlmaLinux Product Errata(セキュリティアドバイザリの公開サイト):https://errata.almalinux.org/
- AlmaLinux Wiki リポジトリ(crb / powertools の有効化):https://wiki.almalinux.org/repos/AlmaLinux.html
- AlmaLinux cloud-images のキックスタート(
01-permitrootlogin.confを作成している箇所):https://github.com/AlmaLinux/cloud-images/blob/main/http/almalinux-9.gencloud-x86_64.ks - Rocky Linux 公式サイト(bug-for-bug 互換の表明):https://rockylinux.org/
- CentOS 公式「CentOS Linux EOL」(CentOS Linux 8 は2021年12月31日):https://www.centos.org/centos-linux-eol/
- CentOS 公式ブログ「End dates are coming for CentOS Stream 8 and CentOS Linux 7」(CentOS Linux 7 は2024年6月30日):https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/
- firewalld 公式ドキュメント(定義済みゾーン):https://firewalld.org/documentation/zone/predefined-zones.html
- firewalld 公式マニュアル firewall-cmd(–permanent と –reload の関係):https://firewalld.org/documentation/man-pages/firewall-cmd.html
- DNF 公式ドキュメント 設定リファレンス(
metadata_expireの既定48時間):https://dnf.readthedocs.io/en/latest/conf_ref.html - DNF 公式ドキュメント dnf-automatic(DNF 4 系):https://dnf.readthedocs.io/en/latest/automatic.html
- DNF5 公式ドキュメント automatic プラグイン(dnf5-automatic.timer):https://dnf5.readthedocs.io/en/latest/dnf5_plugins/automatic.8.html
- DNF5 公式ドキュメント config-manager(
setoptと99-config_manager.repo):https://dnf5.readthedocs.io/en/stable/dnf5_plugins/config-manager.8.html - DNF5 公式ドキュメント advisory コマンド(
advisory list --security):https://dnf5.readthedocs.io/en/latest/commands/advisory.8.html - DNF5 公式ドキュメント「Changes between DNF and DNF5」(updateinfo の扱い・サブコマンド化):https://dnf5.readthedocs.io/en/latest/changes_from_dnf4.7.html
- DNF5 公式ドキュメント needs-restarting プラグイン:https://dnf5.readthedocs.io/en/latest/dnf5_plugins/needs_restarting.8.html
- OpenSSH sshd_config(5) マニュアル(”the first obtained value” と Port の複数指定):https://man.openbsd.org/sshd_config
- Ubuntu launchpad Bug #1991592(openssh に systemd generator を同梱=
sshd-socket-generator):https://bugs.launchpad.net/bugs/1991592 - semanage-port(8) マニュアル(SELinux のポート登録・
-aと-m):https://www.mankier.com/8/semanage-port - localectl(1) マニュアル(システムロケールの設定):https://man7.org/linux/man-pages/man1/localectl.1.html
- hostnamectl(1) マニュアル(ホスト名の設定):https://man7.org/linux/man-pages/man1/hostnamectl.1.html
- ConoHa VPS 公式ドキュメント AlmaLinux イメージ(提供バージョン・接続方法):https://doc.conoha.jp/products/vps-v3/image-v3/image-os-v3/almalinux-v3/
- ConoHa VPS 公式 料金ページ(時間単位の課金):https://vps.conoha.jp/pricing/
- XServer VPS 公式「OS・アプリイメージ一覧」:https://vps.xserver.ne.jp/os-list.php
