著者 CockpitとWebminの違いと選び方
Ubuntu VPSでCockpitとWebminが変更できる範囲、ログイン方法、公開ポートで使う危険性を比較します。2〜3台超ではSSHとAnsibleが適する理由も解説します。
Cockpit と Webmin の比較: 簡単な結論
Cockpit と Webmin は、どちらもブラウザーから Linux サーバーを管理するための Web パネルですが、想定している用途は異なります。Cockpit はディストリビューションの公式リポジトリから提供され、systemd、journald、polkit、udisks を通じてマシンの状態を取得します。そのため、SSH で引き続き管理するサーバーの状態を確認できます。Webmin はより古く、対応範囲も広いツールです。Cockpit が扱わない Apache、BIND、Postfix、MariaDB など、多数のサービスの設定ファイルを変更します。そのために、root として独自の Web サーバーを実行します。
1 台のサーバーの状態をリアルタイムで確認し、ログを読み、緊急時にターミナルを使いたい場合は Cockpit をインストールします。手作業で設定したくないサービスに対して、フォームベースの設定編集画面が必要な場合は Webmin をインストールします。どちらも、パスワード認証で公開ポートに配置しないでください。すでに 2 台または 3 台を超えるサーバーを運用している場合、実際にはどちらも選ばないのが妥当なことが多く、SSH と Ansible の構成のほうが、どのパネルよりも適切に規模を拡大できます。
各パネルで実際に変更できる内容
Cockpit の基本インストールは小さく、多くの機能は個別のパッケージとして提供されるため、不要なものはインストールせずに済みます。
- systemd のサービスとタイマー: unit ファイルの読み取り、起動、停止、有効化
- unit と優先度でフィルタリングした journal。日付ピッカー付きの
journalctl - ローカルアカウント、グループ所属、認証済み SSH key
cockpit-storagedによるストレージ管理: パーティション、LVM volume group、ファイルシステム、mount pointcockpit-podmanによるコンテナ管理。Podman のみを管理しますcockpit-packagekitによるパッケージ更新cockpit-pcpによる CPU、メモリ、ディスク、ネットワークのグラフ- ブラウザーのタブで使用する root terminal
Ubuntu VPS では、2 つの領域が壊れているように見えますが、実際には壊れていません。Cockpit の Networking ページは NetworkManager のフロントエンドです。一方、Ubuntu の server image は netplan と systemd-networkd を使用するため、このページは表示されないか、空になります。表示させるためにリモートホストへ NetworkManager をインストールしないでください。NetworkManager がインターフェースを引き継ぐため、設定を誤ると SSH セッションも失われます。Cockpit の firewall 操作機能は firewalld のフロントエンドです。Ubuntu は ufw を使用するため、firewall 操作機能は表示されません。端末で引き続き sudo ufw status を実行します。
Webmin は、単一のプログラムではなくサービスごとのモジュール群で構成されているため、より広い範囲を管理できます。
- Apache、nginx、BIND、Postfix、Dovecot、MariaDB、PostgreSQL、Samba のフォームによる設定
- ユーザー、グループ、ディスククォータ
- cron job とシステムクロック
- パッケージ更新、および upload と download に対応した file manager
- iptables 用や firewalld 用を含む firewall のフロントエンド
- 設定ファイルのバックアップ、および他の Webmin サーバーへ変更を反映する cluster module
Webmin の多くのフォームは、/etc 配下にある実際のファイルを編集します。背後に隠れたデータベースはありません。そのため、/etc が version control 下にある場合は、フォームを保存した後に sudo git -C /etc diff を実行すると、module がそこへ書き込んだ内容を確認できます。ただし、MariaDB module や PostgreSQL module のように command を実行したり SQL を実行したりする処理や、/etc の外部にあるファイルへの書き込みは表示されません。この制限の範囲では、Webmin のページが実際に行う処理を把握する最短の方法です。Webmin のインストールと初回ログインの手順では、module tree を詳しく説明します。Virtualmin と Usermin は同じ engine 上に構築された別製品です。それぞれ shared hosting と end user 向けに設計されており、ここで説明した exposure に関する内容をすべて引き継ぎます。
各サービスの認証方式
Cockpit には独自のユーザーデータベースがありません。ログインページは /etc/pam.d/cockpit で PAM（プラグ可能認証モジュール）のスタックを実行するため、アカウントには Unix アカウントが使われ、パスワードには Unix パスワードが使われます。/etc/cockpit/disallowed-users に root が記載されているため、デフォルトでは root によるログインは拒否されます。特権操作は polkit 経由で実行され、インターフェースは変更を行う前にパスワードの再入力を求めます。そのため、権限を昇格するまでページヘッダーに「Limited access」と表示されることがあります。
この設計では、セキュリティを強化したサーバーで問題が発生することがあります。パスワード認証を無効にした鍵のみの SSH ログインを設定している場合、アカウントに使用可能なパスワードが存在しないことがあります。その場合、Cockpit のログインは拒否されますが、ssh は引き続き機能します。サーバー上で確認してください。
sudo passwd -S deploydeploy L で始まる出力は、パスワードがロックされていることを示します。PAM が受け付けられるパスワードがないため、入力したパスワードはどれも機能しません。P は、使用可能なパスワードが設定されていることを示します。Cockpit 自体のログインページは SSH 鍵を受け付けません。鍵が使われるのは、Cockpit がログイン先のマシンから別のホストへ接続するときだけです。
Webmin は独自のユーザーを /etc/webmin/miniserv.users に保存します。これは /etc/passwd とは別です。また、Unix アカウントを使って認証するように設定することもできます。すべてのモジュールへのアクセス権を付与された Webmin ユーザーは、ログインシェルの設定にかかわらず、そのマシン上で root と同等の権限を持ちます。Webmin には TOTP（時間ベースのワンタイムパスワード）機能と、ログインに繰り返し失敗したホストをブロックする機能が組み込まれています。どちらも Webmin Configuration 内で有効にします。Cockpit で 2 要素目の認証を使うには、たとえば libpam-google-authenticator を使用して PAM に追加します。
各製品の更新方法
Cockpit はディストリビューションのパッケージとして提供されます。Ubuntu 24.04 では archive から取得できます。upstream プロジェクトは、より新しいビルドを利用するために backports pocket を推奨しています。
. /etc/os-release
sudo apt update
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl status cockpit.socket
apt policy cockpitapt policy cockpit を実行すると、インストールされているバージョンと取得元のリポジトリが表示されます。パッケージ名を指定せずに実行した apt policy は、各取得元の優先度だけを一覧表示します。backports に新しいビルドがない場合、apt は archive のバージョンにフォールバックします。これは問題ありません。cockpit.socket は active (listening) になっている必要があります。その後、セキュリティ修正は kernel と同じ unattended-upgrades の実行を通じて、すでに信頼している提供元から配信されます。
Webmin は Ubuntu の archive に含まれていません。公式のインストール手順では、最初に Webmin 独自のリポジトリと署名 key を追加します。
curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh
sudo apt-get install webmin --install-recommendsこの script は root として実行されるため、実行前に内容を確認してください。それ以降、サーバー上のすべての apt upgrade で Webmin のリポジトリからもパッケージが取得されます。つまり、このサーバーで root レベルの信頼を置く提供元が 1 つ増えます。これが Webmin の実際のコストです。具体例として、CVE-2019-15107 は複数の 1.9x パッケージに含まれていた backdoor で、認証なしのコマンド実行を可能にしました。この問題がユーザーに届いた原因は、source repository ではなくプロジェクトの build host が侵害されたことでした。ディストリビューションによるパッケージ化でも、この問題を完全には防げません。ただし、自分で維持管理する必要のない build とレビューの工程が追加されます。
公開ポートでどちらも公開すべきでない理由
Cockpit は TCP 9090、Webmin は TCP 10000 で待ち受けます。どちらも自己署名証明書を使用した TLS (transport layer security) です。そのため、最初に表示されるのはブラウザーの警告です。自己署名証明書の作成と信頼では、その警告から分かることと分からないことを説明しています。どちらのポートも常時スキャンされています。また、どちらのパネルからも root に到達できます。そのため、推測されたパスワードや使い回しのパスワードによって、サーバー全体が侵害される可能性があります。
安全な構成は、パネルを localhost にバインドし、SSH トンネル経由でアクセスする方法です。Cockpit では、socket unit を上書きします。
sudo systemctl edit cockpit.socket[Socket]
ListenStream=
ListenStream=127.0.0.1:9090単独の行にある空の ListenStream= は必須です。systemd はリスト形式の設定に追記するため、これがないと unit は元の 0.0.0.0:9090 を保持したまま新しいアドレスを追加します。その結果、パネルは引き続き公開状態になります。上書きを適用し、待ち受け状態を確認します。
sudo systemctl daemon-reload
sudo systemctl restart cockpit.socket
sudo ss -lntp | grep 9090出力には 127.0.0.1:9090 と表示される必要があります。*:9090 または 0.0.0.0:9090 というアドレスは、上書きが適用されていないことを示します。次に、自分のマシンからトンネルを開き、https://localhost:9090 にアクセスします。
ssh -N -L 9090:127.0.0.1:9090 deploy@203.0.113.10ローカルポートはリモートポートと一致している必要はありません。Cockpit は、ブラウザーが送信する Host ヘッダーから想定する origin を組み立てます。そのため、ローカルポート 9999 から https://localhost:9999 にアクセスするトンネルでも同じチェックを通過します。ブラウザーの Host ヘッダーと Origin ヘッダーが同じアドレスを示すためです。ブラウザーと Cockpit の間にあるものが Host を変更すると、チェックは失敗します。元のヘッダーを転送しないリバースプロキシなどが該当します。その場合、ログインページは表示されますが、ログインに失敗し、cockpit-ws が received request from bad Origin を記録します。この行は cockpit.service ではなく cockpit-wsinstance-https@ units の journal に記録されます。そのため、sudo journalctl -u 'cockpit-wsinstance-https@*' で読み取ります。Cockpit が認識するアドレスと異なる公開アドレスを許可するには、/etc/cockpit/cockpit.conf にそのアドレスを指定します。
[WebService]
Origins = https://panel.example.comsudo systemctl restart cockpit で再起動すると、この設定が反映されます。Webmin では、同等の設定が /etc/webmin/miniserv.conf にあります。
bind=127.0.0.1sudo systemctl restart webmin
sudo ss -lntp | grep 10000
ssh -N -L 10000:127.0.0.1:10000 deploy@203.0.113.10Webmin もフォーム送信時に Referer ヘッダーを確認し、別のホストから送信されたように見えるリクエストを拒否します。そのため、リバースプロキシの最初の構成が機能しません。/etc/webmin/config にある referers= の行で、プロキシのホスト名を許可します。同じファイルの webprefix= で、Webmin がパス配下に配置されていることを指定します。
もう 1 つの選択肢は、認証付きリバースプロキシです。前段に nginx を置き、Authentik のシングルサインオン層でログインを処理します。動作しますが、2 番目に適した方法です。プロキシの背後では、パネルが引き続き root として実行されます。また、入口を 1 つではなく 2 つ管理する必要があります。トンネルなら、インターネット向けの待ち受けサービスを追加する必要がありません。すでに保護している SSH key をそのまま利用できます。
すでに本番サービスを稼働させているサーバーで使用するパネル
他の利用者がそのマシンに依存している場合は、2つの理由から Cockpit を選びます。Cockpit は socket activation で起動するため、cockpit-ws はセッションが開いている間だけ実行され、ポートで常駐する root デーモンが存在しません。また、Cockpit は何も所有しません。独自の設定を保存しないため、パッケージを削除しても、すべてのサービスは以前とまったく同じように動作し続けます。一方、Webmin の miniserv.pl は、誰もログインしていない場合でも常駐します。systemctl status webmin を使用すると、実行中のプロセスが消費している常駐メモリを表示して、環境への負荷を確認できます。
Webmin の DNS またはメールモジュールが必要な場合は、それら専用のサーバーを用意してください。1つの役割だけを担い、127.0.0.1 にバインドした Webmin 用サーバーであれば、リスクを限定できます。顧客向けアプリケーションと同じホストで Webmin を共有する構成は適切ではありません。どちらかのパネルを導入する前に、基本設定を済ませてください。新しい VPS で最初の10分間に行う作業では、どちらのパネルも事前に用意されていることを前提とする非 root ユーザーとファイアウォールについて説明しています。
どちらも適さない場合
パネルはサーバー単位で手動操作するため、何を変更したか、なぜ変更したかの記録が残りません。1 台だけなら問題ありません。5 台になると同じ操作を繰り返すことになり、20 台になると、どのサーバーで変更が漏れたのか推測することになります。Cockpit では SSH 経由で他のホストを 1 つのセッションに追加できますが、このホスト切り替え機能は Cockpit 322 以降非推奨です。現在のデフォルトはディストリビューションによって異なり、無効になっている場合は /etc/cockpit/cockpit.conf に AllowMultiHost=yes が必要です。有効にしても、同じ変更を 5 回クリックする必要がある点は変わりません。
代わりに、設定を git リポジトリで管理し、通常の SSH を使用します。1 か所から複数の Linux サーバーを管理する方法では、この構成の基本形を説明しています。最初の Ansible playbookでは、差分として確認できる 1 つのファイルから、すべてのホストに同じファイアウォールルールを適用します。コンテナの運用も同じです。Docker Compose の基本ガイドのように、git に保存したファイルから SSH 経由で docker compose up -d を実行する方が、パネルを操作するより確実です。そもそも Cockpit は Docker を管理しません。
端末操作が不得意な作業にはパネルを使用します。たとえば、メトリクスのグラフを確認したり、40 個の unit のうちどれが失敗したかを特定したりする場合です。2 回を超えて実行する作業には、コードを使用してください。
失敗パターンと表示される文字列
Cockpit が SSH では受け付けるパスワードを拒否する。 アカウントが鍵認証専用です。sudo passwd -S alice の第 2 フィールドに L と表示されるため、PAM には確認するパスワードがありません。sudo passwd alice でパスワードを設定するか、そのアカウントは SSH 専用にして、Cockpit には別のユーザーでログインします。
正しいパスワードを入力しても Cockpit が root を拒否する。 /etc/cockpit/disallowed-users に root が表示されます。sudo 権限を持つ一般ユーザーでログインします。これが想定される手順です。polkit が、どのユーザーが権限昇格を実行したかを記録できるためです。
Cockpit に Networking または Firewall ページが表示されない。 これらのページには NetworkManager と firewalld が必要です。Ubuntu VPS は systemd-networkd と ufw を使用するため、これらのページは表示されません。異常ではありません。ufw を引き続き SSH 経由で使用します。
プロキシ経由で Cockpit のログインページは表示されるが、ログインに失敗する。 プロキシが Host ヘッダーを変更したため、Origin の確認に失敗し、sudo journalctl -u 'cockpit-wsinstance-https@*' に received request from bad Origin が表示されます。元の Host を転送するか、/etc/cockpit/cockpit.conf で Origins を設定します。使用するローカルポートに関係なく、通常の SSH トンネルではこの問題は発生しません。
プロキシの背後に配置した後、Webmin のフォーム送信に失敗する。 Referer の確認で拒否されています。/etc/webmin/config の referers= にプロキシのホスト名を追加します。また、パネルをパス配下で提供する場合は、そのファイルで webprefix= を設定します。
パネルが外部公開されているか分からない。 sudo ss -lntp | grep -E '9090|10000' を使用すると、サーバー自体からその状態を確認できます。Webmin はすべてのログイン試行を /var/webmin/miniserv.log に記録するため、待ち受け方法を変更した後に一度確認する価値があります。
FAQ
1 台の Ubuntu VPS では Cockpit と Webmin のどちらが適していますか？
多くの場合は Cockpit です。Ubuntu 自身のリポジトリから提供され、システムの他のパッケージとともにパッチが適用され、ブラウザーセッションを開いている間だけ動作するためです。Cockpit が扱わない BIND や Postfix などのサービスをフォームベースのエディターで編集する必要がある場合は Webmin を選びます。ただし、その場合は Webmin の Web サーバーが常に root として動作し、更新元も Webmin 自身のリポジトリになる点を受け入れる必要があります。
Cockpit と Webmin を同じサーバーで実行できますか？
はい。使用するポートは 9090 と 10000 で異なり、どちらもシステムを直接編集するため、競合しません。ただし、割に合う構成ではありません。同じマシンに root 権限を持つ別々のログイン画面を 2 つ用意することになり、数回のクリックを省くために攻撃対象領域を 2 倍にします。両方をインストールする場合は、両方を 127.0.0.1 にバインドし、SSH トンネル経由でアクセスしてください。
ポート 9090 または 10000 をインターネットに公開しても安全ですか？
パスワードログインでは安全ではありません。どちらのパネルからも root に到達でき、どちらのポートも公開から数時間以内に通常のスキャンで発見されます。パネルを 127.0.0.1 にバインドしてから ssh -N -L 9090:127.0.0.1:9090 user@host を実行し、https://localhost:9090 にアクセスしてください。sudo ss -lntp | grep 9090 で確認し、127.0.0.1:9090 ではなく 0.0.0.0:9090 と表示されることを確認します。認証付きリバースプロキシを使用する方法も許容できる第 2 の選択肢です。
SSH では鍵でログインできるのに、Cockpit のログインに失敗するのはなぜですか？
Cockpit は PAM を通じて Unix パスワードで認証し、ログイン画面では SSH 鍵を受け付けません。セキュリティを強化したサーバーでは、アカウントに使用可能なパスワードが設定されていないことがよくあります。sudo passwd -S youruser を実行してください。2 番目のフィールドが L である場合、パスワードはロックされています。そのため PAM が受け付ける認証情報がなく、すべての試行が拒否されます。sudo passwd youruser でパスワードを設定するか、パネル用に別のアカウントを使用してください。
Cockpit は Docker コンテナを管理できますか？
いいえ。Cockpit のコンテナページは cockpit-podman に由来し、Podman を管理します。以前の Docker モジュールは数年前に削除されており、復活する予定もありません。サービスを Docker で実行している場合は、バージョン管理下の compose ファイルを SSH 経由で使用して管理し、ジャーナルやディスクなど、周辺のシステムを Cockpit に管理させてください。