Ubuntu リモート開発セットアップ — Tailscale + SSH + VS Code Remote で Wayland ホストに繋ぐ

🎯 はじめに：この記事のスコープ

シリーズ「脱Microsoft・OSS移行」は、ここまで ハードウェア → OS → 開発環境 → データ層 → Microsoft 365 → Google Workspace と積み上げてきました。第 7 回は 「Ubuntu 26.04（Wayland）の開発機を外から触る」 仕上げのフェーズです。

💡 既存の L2TP → Tailscale RDP 移行記事 との違い： あちらは Windows ホストへ mstsc / RDP で繋ぐ前提でしたが、本記事は Linux (Wayland) ホストを対象にします。Wayland では RDP 系プロトコルが軒並み詰む（後述）ため、戦略を「画面転送」から「セッション転送（SSH + VS Code Remote）」へ切り替える必要があります。Tailscale は両方の記事で共通の土台です。

🚫 なぜ「Wayland ホスト + GUI RDP」は詰むのか

Kubuntu 26.04（および GNOME 含む Ubuntu 26.04 全般）は Wayland がデフォルトかつ実質唯一のサポートセッションです。X11 セッションは公式サポート対象外で、追加インストール後もログイン画面の選択肢に出ないケースが多発します。

ここに「画面転送 SaaS / RDP プロトコル」を被せようとすると、ほぼすべてが X11 を前提にしている結果、以下のように軒並み倒れます：

Wayland が「リモート画面」を嫌う構造的理由

Wayland はセキュリティ設計上、コンポジターのスクリーンバッファに第三者プロセスがアクセスすることを禁止します（X11 では xrandr や Xorg の拡張で外から自由に画面を覗けたのが問題視されていた）。RDP / VNC / CRD はまさにこの「画面バッファを外から読み出す」操作を必要とするため、Wayland コンポジター（KWin / Mutter / wlroots）が明示的に許可した方法でしか流せないのです。

KWin 6 系は org.freedesktop.portal.ScreenCast で画面共有 API を提供していますが、これを使って「ログオフ済みのデスクトップに再ログインする」フルセッション RDP は 2026 年 5 月時点で安定したオープン実装が存在しません。

結論：画面を運ぶのを諦め、セッションを運ぶ

「画面のピクセルを送る」モデルが詰むなら、「開発セッションそのものを送る」モデルに切り替えればよい。これが Tailscale + SSH + VS Code Remote SSH の組み合わせです：

• ターミナル作業 → SSH で十分（ローカル端末から tmux セッションに attach）
• VS Code（GUI 開発）→ VS Code Remote SSH 拡張 がエディタの UI だけクライアント側でレンダリングし、ファイル I/O・拡張機能・LSP・デバッガはすべてリモート側で実行
• コンテナ作業 → Dev Containers 拡張で Remote SSH 上にさらにコンテナを重ねる
• ブラウザでサーバー確認 → VS Code Remote の ポートフォワードで localhost:3000 がローカル端末で開ける

つまり「Wayland リモートデスクトップ」を求める発想を一度棄てるのが、業務開発機としては圧倒的に楽です。

✅ 結論：Tailscale + SSH + VS Code Remote の三層構成

💡 既存の L2TP→Tailscale 記事 の補完関係： Tailscale 自体の設計思想・ACL・Subnet Router・Unattended Mode などの基礎は既存記事に詳しいので、本記事ではそれ前提で Ubuntu 側 sshd の整備 / VS Code Remote SSH の設定 / Windows クライアントから繋ぐときの落とし穴 に絞ります。

🐧 Phase 7-1: Ubuntu 側のセットアップ（リモート受け側）

Tailscale の導入と起動

Ubuntu 26.04 では公式インストールスクリプト一発で入ります（既存記事 同様）：

curl -fsSL https://tailscale.com/install.sh | sh

sudo tailscale up
# → ブラウザが開くので Google アカウント等でログイン
# → Tailscale Admin Console にデバイスが現れる

Tailscale IP（CGNAT 帯 100.x.x.x のうちの 1 つ）を確認：

tailscale ip -4
# 例: 100.x.x.x （本記事では <tailscale-ip> と表記）

MagicDNS で IP を覚えなくて済むようにする

Tailscale 管理コンソールで MagicDNS を有効化すると、デバイス名で名前解決できるようになります：

これで ssh <user>@ubuntu-dev や ssh <user>@ubuntu-dev.<tailnet-name>.ts.net でも繋がるようになります。IP を引き継ぐ運用が消えるのが地味に大きい効果です。

Unattended Mode（ログオフ中も Tailscale を生かす）

Ubuntu の Tailscale は systemd ユーザーサービスではなく システムサービスとして常駐するため、デフォルトで OS 起動後はログオフ中でも有効です。systemctl status tailscaled で確認：

systemctl status tailscaled
# Active: active (running) since ...

💡 Windows 側だと Unattended Mode を明示的に有効化する必要がありますが（既存記事 L2TP→Tailscale参照）、Linux 側はインストール時点で常時起動が前提です。

OpenSSH サーバーの常時待ち受け化

Ubuntu Desktop には openssh-server がデフォルトで入っていないことがあります。導入と起動：

# インストール（既に入っていれば no-op）
sudo apt update
sudo apt install -y openssh-server

# 起動 + 自動起動有効化
sudo systemctl enable --now ssh
# 26.04 のサービス名は ssh（sshd ではなく）

確認：

systemctl status ssh
# Active: active (running)

ss -tlnp | grep :22
# LISTEN 0 128 *:22 *:*

鍵認証だけにする（パスワード認証を無効化）

Tailscale 経由で来る前提とはいえ、パスワード認証は無効化しておきます。tailscale up --shields-up でデフォルト Drop にしていても、攻撃面は最小化するのが原則：

sudo nano /etc/ssh/sshd_config

以下に書き換え：

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
ChallengeResponseAuthentication no
UsePAM yes  # Ubuntu のロケール等で必要

⚠️ PermitRootLogin no を最優先で。 root にいきなり SSH させる構成は事故時の影響範囲が違いすぎます。sudo 経由で必要な作業は普通のユーザーから走らせる。

再読み込み：

sudo systemctl reload ssh

sleep / suspend の完全無効化（リモート前提なら必須）

Ubuntu 26.04 はデスクトップ用途では一定時間後にサスペンドする設定が入っています。「外から繋ごうとしたら寝ていた」という事故を避けるため、リモート前提の業務開発機ではサスペンドを完全に止めます（第 3 回 § サスペンドの完全無効化で詳述済み）：

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

KDE Plasma の電源管理 GUI 側でも以下を OFF にしておくと安全：

• System Settings → Energy → On Battery Power → Suspend session → Do nothing
• System Settings → Energy → On AC Power → Suspend session → Do nothing
• System Settings → Display → Turn off screen → Never（運用ポリシーによる）

💡 画面ロックは残しておいて OK。 画面ロックは SSH や VS Code Remote の接続を切らない。切れるのは「サスペンド」「ハイバネート」だけ。

💻 Phase 7-2: クライアント側のセットアップ（Windows / Mac / iPhone）

鉄則：Windows から繋ぐなら、Windows ネイティブの鍵を使え

ここが Linux 移行直後のチームで最も踏まれるハマりです。整理しておきます：

つまり、WSL ターミナルから ssh が通っても、VS Code Remote SSH は別の鍵を見にいくので失敗します。WSL 上に開発環境を構築していたユーザーは、ここで体感的に「片方は通って片方は落ちる」現象に遭遇しがちです。

結論：Windows から VS Code Remote SSH で Ubuntu に繋ぐなら、PowerShell（cmd でも可）で鍵を作り、その公開鍵を Ubuntu の authorized_keys に登録する。

Windows ネイティブ PowerShell での鍵作成

PowerShell（Windows ターミナル / コマンドプロンプトでも可。WSL ではない）で：

ssh-keygen -t ed25519 -C "<user>@cts-g.jp"
# Enter to accept default path: C:\Users\<user>\.ssh\id_ed25519
# パスフレーズは業務 PC では空でも可（Tailscale + 物理アクセス制御に頼る方針）
# 厳格運用ならパスフレーズ + ssh-agent

# 公開鍵を表示してコピー
type C:\Users\<user>\.ssh\id_ed25519.pub
# → "ssh-ed25519 AAAA... <user>@cts-g.jp" をクリップボードへ

Ubuntu 側の authorized_keys に登録

Ubuntu 側で：

mkdir -p ~/.ssh
chmod 700 ~/.ssh

# Windows からコピーした公開鍵を追記
echo 'ssh-ed25519 AAAA... <user>@cts-g.jp' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

接続確認（Windows PowerShell から）

ssh <user>@ubuntu-dev.<tailnet-name>.ts.net
# Welcome to Ubuntu 26.04 LTS ... と表示されれば成功

MagicDNS が効くまで Tailscale クライアント側で時間がかかる場合は、暫定で生 Tailscale IP（100.x.x.x）を使えば OK：

ssh <user>@100.x.x.x

Mac クライアント

Mac は素直で、~/.ssh/id_ed25519 と ~/.ssh/config だけ揃っていれば VS Code / ターミナル両方で同じ鍵が使えます。

# Mac ターミナルで
ssh-keygen -t ed25519 -C "<user>@cts-g.jp"
cat ~/.ssh/id_ed25519.pub | pbcopy
# → Ubuntu 側 authorized_keys に追記

iPhone / iPad — ターミナル系アプリは Tailscale 必須

Termius / Blink Shell / Apple の Shellfish などの SSH クライアントから直接 SSH できます。Tailscale クライアントを App Store から入れて、同じ Tailnet に参加させるのがいちばん楽：

• Tailscale アプリ起動 → ログイン → トグル ON
• ターミナルアプリ側のホスト設定で <user>@ubuntu-dev.<tailnet-name>.ts.net を指定
• 秘密鍵はターミナルアプリ側で生成 → 公開鍵を Ubuntu の authorized_keys に追記

iPhone から tmux a -t claude できる状態を作れると、出先で「Claude Code が今どこまで進んだか確認する」が可能になります（Claude Code リモートコントロール の発想にも近い使い方）。

🪟 Phase 7-3: VS Code Remote SSH + Dev Container

拡張のインストール

クライアント側（Windows / Mac）の VS Code に以下 2 つを入れます：

💡 Remote Development Extension Pack（ms-vscode-remote.vscode-remote-extensionpack）を入れると上記 2 つ + WSL も一括で入ります。Microsoft のスタックを残す数少ない例外として、VS Code はこの拡張群が脱 Microsoft 後も継続採用ポイント。

~/.ssh/config を整える

Windows なら C:\Users\<user>\.ssh\config、Mac/Linux なら ~/.ssh/config に：

Host ubuntu-dev
    HostName ubuntu-dev.<tailnet-name>.ts.net
    User <user>
    IdentityFile ~/.ssh/id_ed25519
    # ServerAliveInterval が無いと NAT 越えセッションが切れがち
    ServerAliveInterval 60
    ServerAliveCountMax 3

⚠️ HostName には MagicDNS 名を入れるのが結局いちばん楽。 Tailscale のクライアントが落ちて IP が変わっても、MagicDNS 名は再接続後に同じ名前で解決されます。

接続フロー

1. VS Code → F1 → Remote-SSH: Connect to Host → ubuntu-dev を選択
2. プラットフォームを聞かれたら Linux を選ぶ（初回のみ）
3. 「フォルダーを開く」で Ubuntu 側のパス、例 /home/<user>/Projects/<repo> を指定
4. 左下の緑色ステータスバーに SSH: ubuntu-dev が表示されれば成功

これ以降、VS Code 上で開く統合ターミナルは Ubuntu 側の bash、ファイル保存も Ubuntu 側、拡張機能のホストも Ubuntu 側で走ります。クライアント PC はディスプレイとキー入力だけを担当する形になります。

Dev Container を Remote SSH 上で開く

DevContainer のレポジトリ（例 <repo>）を Remote SSH で開いた状態で、F1 → Dev Containers: Reopen in Container：

第 4 回 で構築した DevContainer がそのまま乗ります。ローカル → Ubuntu → コンテナ という 二段リレーになるため、初回コンテナビルドの体感はやや重くなりますが、2 回目以降は Remote SSH のキャッシュが効いて十分実用速度です。

ポートフォワードでブラウザ確認

Ubuntu 側で npm run dev などのローカルサーバーが立ち上がった時、VS Code Remote SSH は 接続中の localhost を自動でポートフォワードします。

• Ubuntu 側で http://localhost:3000 が立つ
• クライアント PC のブラウザで http://localhost:3000 を開くと、Ubuntu 側のサーバーが見える
• VS Code のターミナル下部「ポート」タブで手動追加・削除も可

💡 これが Splashtop / Chrome Remote Desktop には絶対できない芸当です。**「画面ピクセルではなく IP ネットワークが繋がっている」**ことの本領発揮ポイント。

🧪 Phase 7-4: 検証 — 出先から DevContainer まで通すドライラン

以下のチェックリストを ノート PC を実際に外部ネットワーク（モバイル回線 / カフェ Wi-Fi）に切り替えて実行することを強く推奨します：

引っかかりやすいポイント：

🛡️ Phase 7-5: セキュリティ — 開発機をインターネット化しない

Tailscale + SSH は便利ですが、安易に運用するとオフィス内 LAN ごと外に開いてしまう設計でもあります。最低限の防御を組み合わせます。

1. Tailscale 側の ACL でデバイスを絞る

Tailscale Admin Console → Access Controls で、開発機への SSH ポート（22）を「開発メンバーのデバイスからのみ」許可する ACL を書きます：

{
  "acls": [
    {
      "action": "accept",
      "src":    ["group:devs"],
      "dst":    ["tag:dev-host:22"]
    }
  ],
  "groups": {
    "group:devs": ["<user>@cts-g.jp", "..."]
  },
  "tagOwners": {
    "tag:dev-host": ["group:devs"]
  }
}

そのうえで Ubuntu 側にタグ付け：

sudo tailscale up --advertise-tags=tag:dev-host

2. Tailscale 2FA + Device Approval を有効化

• Tailscale Admin Console → Settings → User authentication → 2FA 必須化
• Device approval を ON。新規デバイスが Tailnet に参加するとき手動承認が必要に

これで「個人の Google アカウントが乗っ取られても、Tailnet 加入には別途承認が必要」になり、ゼロトラスト寄りの構成になります。

3. SSH 側のホスト固有設定

/etc/ssh/sshd_config で：

# Tailscale インターフェース経由のみ許可
ListenAddress 100.x.x.x

# rate limit（ブルートフォース対策。実態 Tailscale 上だが念のため）
MaxAuthTries 3
LoginGraceTime 30s

# IPv6 / Tailscale IPv6 を使うなら明示
# ListenAddress fd7a:115c:a1e0::xxxx

ListenAddress を Tailscale IP に絞ると、Ubuntu のオフライン LAN ポートからの SSH すら受け付けなくなるため、業務 PC 側ではローカル管理に必要な経路（USB シリアル / 直接物理アクセス）を残す前提で運用してください。

4. オフィス LAN の Subnet Router 化は慎重に

Tailscale には Subnet Router 機能があり、オフィス LAN 全体を Tailnet から見えるようにできます（既存記事参照）。

しかし、これを有効化すると **「Ubuntu 開発機が踏み台になって社内 NAS や複合機まで到達される」**設計になります。最初は Subnet Router を有効化しないことを推奨。社内 LAN の他機器が必要になったら、必要なホストだけ個別に Tailscale クライアントを入れる方が安全です。

🪤 ハマり集（実機で踏んだもの）

📋 リスクと対策表

✅ 第 7 回まとめ

• Wayland ホストに GUI RDP / VNC / CRD は乗らない。X11 必須プロトコルとコンポジターの設計が根本から競合する。Linux 開発機をメインに据えるなら、画面ではなくセッションを運ぶ
• 三層スタックは Tailscale（L1 NW）+ SSH（L2 セッション）+ VS Code Remote SSH（L3 IDE）。これで DevContainer まで含めて外から触れる
• Windows クライアントは PowerShell ネイティブで鍵を作る。WSL の鍵は VS Code Remote SSH 経由では使われないため別物として扱う
• MagicDNS 名で運用する。CGNAT IP を直接書くと管理コストが上がる
• ssh / tailscaled は systemd で常時起動、sleep / suspend は systemctl mask で完全停止。リモート前提なら必須前提
• Tailscale ACL + 2FA + Device Approval をセットで運用。SSH 側は PasswordAuthentication no / PermitRootLogin no / ListenAddress を Tailscale IP に絞る
• xrdp / Chrome Remote Desktop は入れない。誤って入った場合は完全削除して Wayland セッションを救う
• 既存の L2TP → Tailscale RDP 移行ガイド は Windows ホスト、本記事は Linux (Wayland) ホスト という棲み分け

これで脱 Microsoft 後の Linux 開発機を、出先・自宅・iPhone から触れる業務インフラとして成立させられます。

📚 シリーズ記事

🔗 関連リソース

CTS-KB 内の関連記事

• L2TP から Tailscale へ ― 開発者のためのリモートデスクトップ乗り換えガイド — Tailscale の基礎 + Windows ホスト RDP 視点
• Claude Code リモートコントロール：CLI セッションをスマホ・Web から操る — iPhone / iPad から Tailscale + SSH で Claude Code を触る応用
• Ubuntu 開発環境セットアップ — DevContainer の構築・post-create.sh の管理（本記事の前提）
• Ubuntu PC セットアップ — サスペンド完全無効化（リモート前提なら必須）

関連用語

• Wayland — Ubuntu 26.04 デフォルトのディスプレイサーバープロトコル
• X11 — レガシーディスプレイサーバー。xrdp / CRD が前提とする
• DevContainer — VS Code が解釈するコンテナ化された開発環境定義
• NAT — Tailscale が自動越えする家庭・オフィス回線の前提
• KDE Plasma — Kubuntu 26.04 のデフォルトデスクトップ環境

外部リソース

• Tailscale Docs — Linux — Ubuntu 公式インストール手順
• Tailscale Docs — MagicDNS — <host>.<tailnet>.ts.net の名前解決
• VS Code Docs — Remote Development using SSH — VS Code Remote SSH 公式ドキュメント
• OpenSSH sshd_config man page — 詳細なオプションリファレンス