著者 Matt Connor
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 ボリュームグループ、ファイルシステム、マウントポイントcockpit-podmanによるコンテナ管理。Podman のみを管理しますcockpit-packagekitによるパッケージ更新cockpit-pcpによる CPU、メモリ、ディスク、ネットワークのグラフ- ブラウザーのタブで使用できる root terminal
Ubuntu VPS では壊れているように見える領域が 2 つありますが、実際には壊れていません。Cockpit の Networking ページは NetworkManager のフロントエンドです。Ubuntu のサーバーイメージは netplan と systemd-networkd を使用するため、このページは表示されないか、空になります。ページを復活させるためにリモートホストへ NetworkManager をインストールしないでください。NetworkManager がインターフェースを引き継ぐため、設定を誤ると SSH セッションも失われます。Cockpit の firewall controls は firewalld のフロントエンドです。Ubuntu は ufw を使用するため、ファイアウォールの操作項目は表示されません。引き続き、ターミナルで sudo ufw status を実行します。
Webmin は、1 つのプログラムではなくサービスごとのモジュール群で構成されているため、対応範囲がはるかに広くなっています。
- フォームを使用した Apache、nginx、BIND、Postfix、Dovecot、MariaDB、PostgreSQL、Samba の設定
- ユーザー、グループ、ディスククォータ
- cron ジョブとシステムクロック
- パッケージ更新、およびアップロードとダウンロードに対応したファイルマネージャー
- iptables 用と firewalld 用を含むファイアウォールのフロントエンド
- 設定ファイルのバックアップ、および他の Webmin サーバーへ変更を反映するクラスターモジュール
Webmin は /etc 配下の実ファイルを編集します。フォームの背後に隠れたデータベースはありません。そのため、/etc をバージョン管理している場合は、フォームの保存後に sudo git -C /etc diff を確認すると、モジュールが実際に書き込んだ内容を正確に確認できます。これは、Webmin の各ページが実際に行っている処理を把握する最も速い方法です。Webmin のインストールと初回ログインの手順では、モジュールツリーについて詳しく説明しています。Virtualmin と Usermin は同じエンジン上に構築された別製品で、それぞれ共有ホスティングとエンドユーザー向けに使用されます。ここで説明した公開範囲に関する内容は、これらにも当てはまります。
各サービスの認証方式
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 ではアーカイブからインストールされます。上流プロジェクトは、より新しいビルドを利用する場合に 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 では、インストールしたバージョンと、その取得元リポジトリを確認できます。backports に新しいビルドがない場合、apt はアーカイブ版にフォールバックします。これは問題ありません。cockpit.socket は active (listening) になっているはずです。その後、セキュリティ修正はカーネルと同じ unattended-upgrades 実行で、すでに信頼している提供元から配布されます。
Webmin は Ubuntu のアーカイブに含まれていません。公式のインストール手順では、最初に Webmin 独自のリポジトリと署名鍵を追加します。
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このスクリプトは root として実行されるため、実行前に内容を確認してください。それ以降、サーバー上のすべての apt upgrade で Webmin のリポジトリからもパッケージが取得されます。つまり、そのサーバーに root レベルで信頼する2つ目の提供元を追加することになります。これが Webmin の実質的なコストです。具体例として、CVE-2019-15107 は複数の 1.9x パッケージに存在したバックドアで、認証なしのコマンド実行を可能にしました。この問題が利用者に届いたのは、ソースリポジトリではなく、プロジェクトのビルドホストが侵害されたためです。ディストリビューションによるパッケージ化によって、この事態を完全に防げるわけではありません。ただし、自分で維持管理する必要のないビルドとレビューの工程が追加されます。
公開ポートで公開してはいけない理由
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 は、ブラウザーの Origin ヘッダーと、自身が提供していると認識しているアドレスを比較します。そのため、ローカルポート 9999 からトンネルを作成するとログインページまでは表示されますが、ログイン時に失敗し、journalctl -u cockpit に拒否されたオリジンが記録されます。別のローカルポートが必要な場合は、/etc/cockpit/cockpit.conf で指定します。
[WebService]
Origins = https://localhost:9999 https://127.0.0.1:9999その設定を反映するため、sudo systemctl restart cockpit.socket で再起動します。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 ヘッダーを確認し、別のホストから送信されたように見えるリクエストを拒否します。これにより、リバースプロキシを最初に試すと失敗します。同じファイルにある referers= の行でプロキシのホスト名を許可し、webprefix= で Webmin がパス配下で動作することを指定します。
もう1つの選択肢は、認証付きリバースプロキシです。前段に nginx を置き、Authentik のシングルサインオン層でログインします。動作しますが、最善の方法ではありません。プロキシの背後でもパネルは 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 経由で同じセッションに他のホストを追加できますが、最近のバージョンではこの機能がデフォルトで無効になっており、AllowMultiHost=yes を /etc/cockpit/cockpit.conf に設定する必要があります。それでも、同じ変更を5回クリックして適用することになります。
別の方法は、設定を git リポジトリで管理し、通常の SSH を使うことです。複数の Linux サーバーを1か所から管理する方法では、この構成の基本形を説明しています。初めての Ansible playbookでは、1つのファイルから確認可能な差分として、同じファイアウォールルールをすべてのホストに適用します。コンテナ運用も同じです。Docker Compose の基本ガイドのように、git 内のファイルから SSH 経由で docker compose up -d を実行するほうが、どのパネルでもクリックして操作するより優れています。そもそも Cockpit は Docker を管理しません。
パネルは、メトリクスのグラフを読む、40 個の unit のうちどれが失敗したかを確認するといった、ターミナルが苦手な作業に使います。2回を超えて実行する作業には、コードを使ってください。
障害パターンと表示される文字列
SSH では受け付けられるパスワードを Cockpit が拒否する。 アカウントが鍵認証専用になっています。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 では netplan と systemd-networkd、ufw が動作するため、これらのページは表示されません。故障ではありません。ufw を SSH 経由で使い続けてください。
トンネル経由で Cockpit のログインページは表示されるが、ログインに失敗する。 ローカルポートとリモートポートが異なるため、Origin の確認に失敗し、journalctl -u cockpit にその結果が表示されます。ポートを一致させるか、/etc/cockpit/cockpit.conf で Origins を設定します。
プロキシの背後に配置した後、Webmin のフォーム送信に失敗する。 Referer の確認で拒否されています。/etc/webmin/miniserv.conf の 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 に管理させてください。