著者 Linux VPSでリモートデスクトップを使う方法
Linux VPSで実際のGUIを動かすならxrdpとXFCEが使えます。TCP 3389を公開せずSSH tunnelで接続する手順と、RustDeskを選ぶ場面を解説します。
Linux VPS のリモートデスクトップが実際に意味するもの
「Linux VPS のリモートデスクトップ」で検索すると、2 種類の異なる製品が見つかります。間違ったものを選ぶと、午後を丸ごと費やすことになります。1 つ目は、リモートアクセスブローカーです。RustDesk のセルフホストサーバーが一般的な例です。これは、ノート PC と自宅の PC など、すでに所有している 2 台のマシン間でセッションを中継します。レンタルしたサーバー上でデスクトップは描画されません。2 つの端点を相互に知らせ、直接接続できない場合にパケットを転送します。2 つ目は、レンタルしたサーバー上で実際に動作するグラフィカルデスクトップです。ピクセルはデータセンター内で描画され、ユーザーにストリーミングされます。これが xrdp、VNC（virtual network computing）、またはコンテナワークスペースです。
両者は、1 つの質問で区別できます。これが動作したとき、マウスポインターはどのマシン上にあるでしょうか。すでに所有しているマシン上に置きたいなら、ブローカーが必要です。VPS 自体に置きたいなら、VPS 上のデスクトップが必要です。以下では後者を中心に説明します。多くのガイドがこのケースを省略しているためです。
用途に合う選択肢
- 独自の relay を使用する RustDesk。 見知らぬ第三者が運用する公開 rendezvous server を経由せずにセッションを保護できます。これは key pair を自分で管理するためです。ただし、操作対象のマシン自体は保護されません。保護されるのは、client をインストールした PC と、その PC に設定された password の範囲です。
- SSH tunnel または VPN 経由の xrdp。 TCP 3389 に対するインターネット全体からの継続的なスキャンや、RDP の login 画面に対する password 推測攻撃から保護できます。その port がインターネットに公開されないためです。ただし、すでに tunnel に接続できる相手から、弱い account password を保護することはできません。
- 同じ tunnel 経由の VNC。 RDP より古く単純な protocol を使い、接続が切れても維持される desktop session を利用できます。VNC 単体では何も保護しません。セキュリティ対策はすべて tunnel が担うため、public port で VNC だけを公開する構成は、この中で最も危険な選択肢です。
- Webtop や Kasm などの container workspace。 browser または完全な desktop を container 内で利用できます。その container は破棄して再構築できるため、browser が触れる対象から実際のマシンを保護できます。ただし、host は保護されません。これらの image は広い権限で動作し、内部に passwordless の
sudoがあるため、敵対的な workload を任せられる境界として container を信頼すべきではありません。
Ubuntu 24.04 に xrdp と XFCE をインストールする
VPS のサーバーイメージには、グラフィカルデスクトップが含まれていません。まずデスクトップをインストールし、次に RDP（リモートデスクトッププロトコル）を使用するオープンソースサーバーの xrdp をインストールします。xrdp は Windows クライアントと同じプロトコルを使用します。軽量なデスクトップを選ぶ場合、通常は XFCE を使用します。
sudo apt update
sudo apt install -y xrdp xorgxrdp xfce4 xfce4-goodies dbus-x11
systemctl is-active xrdp2026 年 8 月時点で、Ubuntu 24.04 の universe コンポーネントには xrdp 0.9.24 と xorgxrdp が含まれています。xorgxrdp は推奨パッケージにすぎませんが、名前を指定してインストールしてください。これは、新しいセッション用に xrdp が起動する X サーバーバックエンドです。これがない場合、ログイン画面でパスワードを受け付けた直後に、再びログイン画面へ戻されます。
次に、セッションで起動するデスクトップを指定します。xrdp は /etc/xrdp/startwm.sh を実行し、このファイルが存在すると ~/.xsession を実行します。
echo "xfce4-session" > ~/.xsession
chmod 644 ~/.xsession最後に、xrdp はクライアントへ提示する TLS（トランスポート層セキュリティ）鍵を読み取る必要があります。このファイルのモードは 640 で、所有グループは ssl-cert です。
ls -l /etc/ssl/private/ssl-cert-snakeoil.key
id xrdp一覧には -rw-r----- 1 root ssl-cert が表示されます。id xrdp を実行してもグループ一覧に ssl-cert が表示されない場合は、sudo adduser xrdp ssl-cert を実行し、その後 sudo systemctl restart xrdp を実行します。これを省略すると xrdp は鍵を開けず、/var/log/xrdp.log が行内に snakeoil のファイル名を含むエラーを記録します。
インターネットにポート 3389 を公開してはいけない理由
TCP 3389 はインターネット上のあらゆる接続元から継続的にスキャンされており、RDP のログイン画面はパスワード試行のたびに応答します。公開してはいけません。代わりに xrdp を loopback アドレスにバインドし、信頼できるトンネル経由で接続します。
/etc/xrdp/xrdp.ini を編集し、[Globals] セクションのリスナーを変更します。
[Globals]
port=tcp://.:3389配布されているファイルには、その構文がコメントで説明されています。tcp://.:3389 は 127.0.0.1:3389 を意味し、tcp://:3389 はすべてのインターフェースを意味します。ここでの入力ミスにより、サービスがすべてのアドレスで待ち受けたままになることがあるため、再起動して確認します。
sudo systemctl restart xrdp
ss -tlnp | grep 3389必要なのは 127.0.0.1:3389 です。0.0.0.0:3389 が表示される場合、xrdp は編集内容を適用していません。通常は、ファイル内の後方にある別のセクション見出しの下に行が入っています。
次に、自分のマシンからトンネルを開きます。
ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com-N は「接続だけを開き、コマンドは実行しない」という意味です。そのため、このセッションはポート転送専用になります。そのターミナルは開いたままにし、RDP クライアントから 127.0.0.1:3389 に接続します。Linux クライアントでは FreeRDP 3 を使用します。Ubuntu 24.04 でのバイナリ名は xfreerdp3 です。
sudo apt install -y freerdp3-x11
xfreerdp3 /v:127.0.0.1:3389 /u:you /dynamic-resolution +clipboard /soundWindows では組み込みの mstsc を使用し、コンピューターとして 127.0.0.1 を入力します。初回接続時、FreeRDP は証明書を信頼するか確認し、Do you trust the above certificate? (Y/T/N) と表示します。これは自己署名の snakeoil 証明書を使用しているためで、正常な動作です。
ssh が bind [127.0.0.1]:3389: Address already in use と応答する場合、自分のマシン上ですでに何かが 3389 を使用しています。ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com でローカル側のポートを変更し、127.0.0.1:13389 に接続します。
利用者ごとにトンネルを作成する方法は手間がかかります。チームで利用する場合は、プライベートネットワークの方が適しています。自己ホスト型 WireGuard VPN の背後にサーバーを配置し、トンネルアドレス 10.8.0.1 を割り当て、xrdp が VPN 内部からのみ応答するよう port=tcp://10.8.0.1:3389 を設定します。どちらの方法でも、3389 のファイアウォールルールは一切設定しないでください。現在のルールで何が許可されているか不明な場合は、VPS の ufw ファイアウォールの基本から確認し、接続後ではなく接続前に調べてください。
2 GB VPS でリモートデスクトップが使用する RAM の量
選択するデスクトップによって、2 GB プランを快適に使えるか、実用にならないかが決まります。以下は、Ubuntu 24.04 でログイン直後に使用されるメモリの典型的な値を丸めたものです。手元のマシンで測定した値ではなく、公開されている比較結果に基づいています。接続直後に free -m を実行して、自分の環境を測定してください。
The data behind this chart
[
{
"label": "LXQt",
"idle_ram_mb": 300
},
{
"label": "XFCE",
"idle_ram_mb": 400
},
{
"label": "MATE",
"idle_ram_mb": 500
},
{
"label": "KDE Plasma",
"idle_ram_mb": 800
},
{
"label": "GNOME",
"idle_ram_mb": "1,200"
}
]これら 5 種類のデスクトップでは、使用量の差が重要です。LXQt は 300 MB 前後、XFCE は 400 MB 前後なので、どちらも 2 GB のサーバーでブラウザーを動かす余裕が残ります。GNOME はウィンドウを 1 つも開いていない状態で約 1,200 MB を必要とするため、2 GB では残りのメモリをブラウザーとデスクトップが奪い合うことになります。
本当の負荷になるのはデスクトップシェルではなく、ブラウザーです。最新のブラウザーは、アクティブなタブ 1 つあたり 150～400 MB 程度を使用するため、XFCE を実行する 2 GB VPS では、数個のタブを開くとスワップが始まります。プロセスを強制終了する代わりにマシンの動作を遅くできるよう、スワップを追加します。まず sudo fallocate -l 2G /swapfile、続いて sudo chmod 600 /swapfile、sudo mkswap /swapfile、sudo swapon /swapfile を実行し、再起動後も維持されるよう /etc/fstab に対応する行を追加します。警告なしに何かが終了した場合は、dmesg | grep -i "killed process" を実行してください。その行は、カーネルの out-of-memory killer がプロセスを終了したことを示します。通常、その対象になるのはブラウザーです。
もう 1 つの制限は CPU で、こちらは過小評価しやすい点です。VPS には GPU がないため、X は llvmpipe によるソフトウェアレンダリングにフォールバックします。つまり、すべてのピクセルを CPU が描画します。負荷の高いページのスクロールや動画の再生は、いずれも通常の CPU 負荷として現れます。マシンが停止するのではなく、フレームレートが低下します。これは VPS でゲームを実行できるか を考えたときに直面する制約と同じです。3D の用途では答えは no であり、その理由もまさにこれです。
xrdp セッションでのサウンドとクリップボード
Ubuntu 24.04 はオーディオに PipeWire を使用します。一方、xrdp のサウンドリダイレクトは PulseAudio 向けに実装されています。そのため、新規インストール直後は映像は機能しても音声は出ません。Ubuntu にはこのためのブリッジが用意されています。
sudo apt install -y pipewire-module-xrdp pulseaudio-utils alsa-utilsRDP セッションから完全にログアウトして、もう一度ログインします。セッション開始時にモジュールが読み込まれるためです。再接続だけでは不十分です。次に、セッション内で確認します。
pactl list short sinks
speaker-test -c 2 -t wav -l 1名前に xrdp を含むシンクが表示され、クライアントからテスト音が聞こえるはずです。xrdp シンクが表示されない場合、このセッションにモジュールが読み込まれていません。クライアント側でもオーディオを要求する必要があります。これは xfreerdp3 の /sound フラグ、または Windows クライアントの Local Resources にある「Remote audio」設定で指定します。
xrdp-chansrv がセッションで実行されていれば、テキストのクリップボードは双方向で機能します。xrdp がこのプロセスを起動するため、pgrep -a xrdp-chansrv で確認できます。セッションの途中でコピーと貼り付けが機能しなくなった場合は、そのプロセスが終了しています。再接続するとプロセスが再起動します。テキストではなくファイルをコピーする機能は、drive redirection と呼ばれる別のチャネルです。xfreerdp3 上の /drive:home,/home/you により、ローカルフォルダーがリモートセッション内にマウントされます。
polkit のポップアップと、初回ログイン時に発生するその他の失敗
初回ログイン時に最もよく表示されるのは、Authentication is required to create a color managed device というダイアログです。原因は明確です。colord サービスは polkit に許可を要求します。polkit は、ローカルに着席していると判断したセッションに対してのみ、その操作を暗黙に許可します。RDP セッションは着席セッションではないため、polkit はパスワードの入力を求めます。Ubuntu 24.04 には polkit 124 が含まれています。polkit 124 では、従来のローカル authority ファイル .pkla が削除されています。そのため、/etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla を作成するよう案内する手順は、24.04 ではまったく効果がありません。代わりに JavaScript ルールを作成します。
/* /etc/polkit-1/rules.d/45-allow-colord.rules */
polkit.addRule(function(action, subject) {
if (action.id.indexOf("org.freedesktop.color-manager.") === 0 &&
subject.isInGroup("sudo")) {
return polkit.Result.YES;
}
});sudo systemctl restart polkit を実行してから再接続します。症状で判別できる、ほかの2つの失敗も確認しておきます。
ログイン画面でパスワードを入力すると、すぐに同じ画面へ戻る。 セッションは開始しましたが、終了しています。まず /var/log/xrdp-sesman.log を読み、次にホームディレクトリ内の ~/.xsession-errors を確認します。xorgxrdp がない場合、インストールされていないデスクトップを指定する ~/.xsession がある場合、書き込みできないホームディレクトリを使用している場合、またはディスク容量が不足している場合は、いずれもこの症状になります。
接続すると、X カーソルのある灰色の画面が表示される。 X は起動しましたが、デスクトップは起動していません。これも ~/.xsession が原因です。SSH 経由で xfce4-session を手動実行し、表示されるエラーを確認します。
セルフホストの RustDesk サーバーの役割
RustDesk は 2 つのプロセスに分かれています。hbbs はクライアントが登録する ID サーバー兼ランデブーサーバーで、hbbr は直接のピアツーピア接続に失敗した場合にセッションを中継します。どちらもデスクトップ環境は実行しません。両方とも 1 つのイメージに含まれています。以下はプロジェクトが公開している compose ファイルで、リレーのアドレスだけを自分のホスト名に変更しています。
services:
hbbs:
container_name: hbbs
image: rustdesk/rustdesk-server:latest
command: hbbs -r rustdesk.example.com:21117
ports:
- 21115:21115
- 21116:21116
- 21116:21116/udp
- 21118:21118
volumes:
- ./data:/root
restart: unless-stopped
hbbr:
container_name: hbbr
image: rustdesk/rustdesk-server:latest
command: hbbr
ports:
- 21117:21117
- 21119:21119
volumes:
- ./data:/root
restart: unless-stopped起動したら、初回起動時にサーバーが生成した公開鍵を確認します。
sudo docker compose up -d
sudo cat ./data/id_ed25519.pubすべてのクライアントで、RustDesk クライアントの Network 設定にホスト名と公開鍵を入力する必要があります。対応する秘密鍵は ./data/id_ed25519 に保存されます。データディレクトリを削除すると、サーバーは新しい鍵ペアを生成します。その場合、すべてのクライアントで新しい鍵を再設定する必要があります。このディレクトリはバックアップしてください。週末の実験ではなく、チームがすべてのマシンへ接続するための構成として使う場合は、RustDesk リレーの専用ビルドも確認する価値があります。Ed25519 鍵の扱い、latest ではなく固定したイメージタグの使用、契約プランで料金が発生するリレー帯域幅について説明しています。
ファイアウォールでは、これらのポートへの直接アクセスを許可する必要があります。hbbs は TCP 21115、21116、21118 と UDP 21116 を使用します。hbbr は TCP 21117 と 21119 を使用します。
sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcpNginx や Traefik の背後で RustDesk が動作しない理由
すべての TLS 終端を 1 台のリバースプロキシで処理している環境では、この構成を試して失敗することがあります。hbbs と hbbr は HTTP ではなく、TCP と UDP 上で独自のバイナリプロトコルを使用します。ルーティングに使える Host ヘッダーも、検査できる HTTP リクエストもありません。そのため、nginx の server ブロックや Traefik の HTTP ルーターには照合対象がありません。21116 番ポートの UDP リスナーは、どの層でも HTTP ではありません。
機能する方法は 2 つあります。nginx では stream ブロックを使って TCP ポートを転送できます。これは通常の意味でのリバースプロキシではなく、単純なレイヤー 4 転送です。また、21118 番ポートと 21119 番ポートでは RustDesk の Web クライアントが使用する WebSocket が流れます。WebSocket は通常の HTTP なので、この 2 つはプロキシの背後に置けます。その場合は、プロキシだけが 21118 番ポートと 21119 番ポートへ接続できるようファイアウォールルールを追加してください。hbbs は WebSocket 接続の X-Real-IP ヘッダーを信頼して、実際のクライアントアドレスを特定するためです。
コンテナ内の使い捨てブラウザー
必要なのが、IP アドレスが変わらず、自分のマシンから隔離されたクリーンなブラウザーだけという場合があります。コンテナのワークスペースなら、インストールするソフトウェアを大幅に減らして実現できます。LinuxServer の Webtop は軽量な選択肢です。
services:
webtop:
image: lscr.io/linuxserver/webtop:latest
container_name: webtop
environment:
- PUID=1000
- PGID=1000
- TZ=Etc/UTC
volumes:
- /path/to/data:/config
ports:
- 127.0.0.1:3000:3000
- 127.0.0.1:3001:3001
shm_size: "1gb"
restart: unless-stoppedポート 3000 では HTTP、3001 では HTTPS を提供します。RDP クライアントを用意せず、ブラウザーのタブからデスクトップに接続できます。イメージタグでは、複数のベースディストリビューション上の XFCE、KDE、MATE、i3 が提供されています。プロジェクトの公式ドキュメントはリスクを明確に説明しています。このコンテナはホストに対する特権アクセスを持ち、パスワードなしで sudo を実行できるターミナルも含みます。そのため、保護せずにインターネットへ公開すべきではありません。上記のポートをすべてのアドレスで公開せず、127.0.0.1 にバインドするのはそのためです。xrdp で使用したものと同じ SSH トンネルまたは VPN 経由で接続します。
Kasm Workspaces も同じ発想ですが、Web コンソール、ユーザーアカウント、セッション終了時にリセットされるセッションごとのコンテナを備え、規模が大きくなります。小規模な VPS より多くのリソースが必要です。2026 年 8 月時点で、ドキュメントに記載された最小要件は CPU 2 コア、メモリ 4 GB、SSD 50 GB です。さらに、各ユーザーセッションではデフォルトで CPU 2 コアと 2768 MB が使用されます。2 GB プランでは実行できません。インストールはダウンロードとスクリプトの実行で行います。
cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz
tar -xf kasm_release_1.17.0.7f020d.tar.gz
sudo bash kasm_release/install.shVNC と、現在でも適する用途
VNC は描画コマンドではなくフレームバッファーの更新を送信するため、低速な接続では RDP より重く感じられ、音声チャンネルもありません。VNC を選ぶ意味があるのは、切断後もデスクトップセッションを実行し続け、戻ったときに同じセッションを再開したい場合です。TigerVNC がこの用途に対応します。vncserver -localhost yes :1 は Xvnc を TCP 5901 の 127.0.0.1 にバインドし、それ以外からの接続を拒否します。そのため、ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com を使用して xrdp と同じ方法でトンネルします。VNC のポートを公開してはいけません。多くの VNC サーバーはハンドシェイク中のパスワードだけを保護し、その後の通信は保護しません。公開ポートで運用すると、セッションの内容がネットワーク上で読み取られます。
VPS はデスクトップとして適していますか？
日常的に使う環境としては、適していません。理由はいくつもあります。GPU がないため、描画はすべて CPU が処理します。キー入力のたびにネットワークの往復を待つ必要があり、SSH では問題のない 40 ms のレイテンシーでも、テキストエディターでは遅延として感じられます。動画は、サイト側と RDP エンコーダーによって 2 回圧縮されます。ファイルは自分が直接管理していないディスク上に保存されます。また、デスクトップを長時間使うと、Web サーバー向けに設定された月間帯域幅上限を消費します。
一時的に使い捨てるマシンとしては、とても適しています。その理由も同じ特性にあります。IP アドレスは固定され、データセンターに属しています。サービスから一貫したアドレスとして認識させたい場合に適しています。マシンはイメージから数分で再構築できるため、セッションで悪意のあるものを取得しても、失うものはありません。実際のハードウェアから分離されており、ノート PC を閉じても動作し続けます。時間単位の課金であれば、使い捨てのデスクトップを安価に利用できます。
このマシンの用途をまだ決めていない場合は、デスクトップをインストールする前に、VPS が得意とする実用的な用途の一覧を読むとよいでしょう。デスクトップが必要な理由が Windows アプリケーション 1 つだけであれば、まず Linux と Windows Server の実際の違いと比較してください。ライセンスによって、その選択にかかる費用が変わるためです。
FAQ
2 GB の VPS でリモートデスクトップを実行できますか？
はい。軽量なデスクトップ環境を使用してください。XFCE または LXQt はログイン後におよそ 300 から 400 MB を使用するため、タブを数個開いたブラウザーを動かす余裕が残ります。2 GB で GNOME または KDE Plasma を使用すると、アプリケーション用のメモリはほとんど残りません。2 GB の swap ファイルを追加すると、メモリ不足時にプロセスが強制終了される代わりに、マシンの動作が遅くなります。何かがメッセージなしで消えた場合は、カーネルの out-of-memory killer について dmesg | grep -i "killed process" を確認してください。
VPS のファイアウォールでポート 3389 を開くべきですか？
いいえ。TCP 3389 は常にスキャンされており、RDP のログイン画面を公開するとパスワード推測攻撃を招きます。/etc/xrdp/xrdp.ini で port=tcp://.:3389 を設定し、xrdp が 127.0.0.1 のみで待ち受けるようにしてください。ss -tlnp | grep 3389 で設定を確認し、ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com で接続します。利用者が 1 人か 2 人を超える場合は、loopback ではなく WireGuard のアドレスに xrdp を bind してください。
xrdp が「Authentication is required to create a color managed device」と表示するのはなぜですか？
colord サービスは polkit に権限を要求します。polkit がその操作をパスワードなしで許可するのは、ローカルで着席しているセッションだけです。RDP セッションはその条件を満たさないため、ログインするたびにパスワードを求められます。Ubuntu 24.04 では、以前の .pkla による修正は機能しません。polkit 124 で local authority ファイルが廃止されたためです。org.freedesktop.color-manager. で始まる action id に対して polkit.Result.YES を返す JavaScript ルールを /etc/polkit-1/rules.d/45-allow-colord.rules に作成し、その後 sudo systemctl restart polkit を実行してください。
self-hosted RustDesk サーバーを nginx または Traefik の背後に配置できますか？
主要サービスは配置できません。hbbs と hbbr は HTTP ではなく独自のバイナリプロトコルを使用するため、ルーティングに使用できる Host ヘッダーがありません。また、UDP 21116 は HTTP プロキシを通過できません。ファイアウォールで TCP 21115 から 21119 と UDP 21116 を開き、クライアントから直接接続させてください。Web クライアントが使用する websocket ポート 21118 と 21119 は HTTP のため、プロキシの背後に配置できます。その場合は、プロキシからの接続だけを許可するようファイアウォールで制限してください。これらの接続では hbbs が X-Real-IP を信頼するためです。
xrdp セッションで音声が出ないのはなぜですか？
Ubuntu 24.04 は PipeWire を使用します。一方、xrdp の音声リダイレクトは PulseAudio 向けに構築されているため、bridge をインストールするまで音声がありません。sudo apt install -y pipewire-module-xrdp を実行し、セッションから完全にログアウトしてから再度ログインしてください。モジュールはセッション開始時に読み込まれるため、再接続だけでは読み込まれません。pactl list short sinks で xrdp という名前の sink を確認し、クライアントが音声を要求していることも確認してください。xfreerdp3 では /sound flag、Windows クライアントでは「Remote audio」に該当します。