VS Code Remote-SSHでオフラインLinuxに接続できない｜Serverを手動配置して直した手順

2台のWindows PCとオフラインLinux機を並べたRemote-SSH作業環境 開発環境
2026.04.18

オンライン側のWindowsからRDPで閉域側のWindowsへ入り、そこからさらにLinuxへRemote-SSHで接続する。私が詰まったのは、この少し回りくどい構成でした。

通常のsshコマンドではLinuxに入れるのに、VS CodeではFailed to download VS Code Server (Failed to fetch)で止まる。Linux側にServerを展開しても、またダウンロードを始めようとする。最後はSSH鍵の設定まで疑い始めて、問題が混ざっていました。

先に結論を書くと、見るべきだったのは次の3点です。

  1. 実際にRemote-SSHを動かすWindowsのVS Code commit
  2. Linux側でRemote-SSHがServerを探しているパス
  3. SSH接続とVS Code Server起動を分けて確認すること

この記事は一般的なRemote-SSH入門ではなく、接続元も接続先もインターネットへ出られない環境で、実際に直した順番の記録です。私の環境ではVS Code 1.111.0、接続先はLinux x64でした。VS CodeとRemote-SSHの更新でパスやアーカイブ名は変わり得るため、手元のログを優先してください。

今回の接続構成

オンラインWindowsからRDPでオフラインWindowsに入り、そこからRemote-SSHでオフラインLinuxへ接続する構成図
Remote-SSHの接続元は真ん中のオフラインWindowsです。Serverアーカイブはオンライン側から物理移送しました。

ここで一番重要なのは、Remote-SSHから見た「ローカルPC」は真ん中のオフラインWindowsだという点です。手前のオンラインWindowsではありません。

Microsoftの説明では、Remote-SSHは通常、接続先でVS Code Serverをダウンロードし、失敗するとローカル側で取得して転送します。ただし今回のローカル側はオフラインWindowsです。remote.SSH.localServerDownloadをalwaysにしても、そのWindows自体がMicrosoftの配布先へ出られないので解決しません。

そのため、オンラインWindowsでServerアーカイブを用意し、USBなどの管理された媒体でオフラインWindowsへ運び、そこからLinuxへ転送しました。

1. まず通常のSSHだけで入れるか確認する

Remote-SSHを触る前に、オフラインWindowsのPowerShellから通常のSSH接続を試します。

ssh linux-user@linux-host

ここで入れない場合は、VS Code Serverより先にネットワーク、sshd、ユーザー名、鍵認証を直します。ここで入れるのにRemote-SSHだけ失敗するなら、Serverの取得・配置・起動へ切り分けられます。

通常のSSH接続とVS Code Server起動を分けて確認する図
通常のSSHが通るかを先に確認し、Remote-SSH固有の問題と分けます。

VS Codeでは表示 → 出力を開き、プルダウンからRemote – SSHを選びます。通知に出た一行だけでなく、まず次の文字列を探しました。

  • Using commit id
  • server download URL
  • Found existing installation
  • Remote server is listening

Using commit idの値と、次に確認するcode --versionのcommitが違っていれば、配置したServerも合いません。

2. 接続元VS Codeのcommitを確認する

オフラインWindowsで次を実行します。

code --version

出力はおおむね次の並びです。

1.111.0
<40文字のcommit>
x64

使うのは2行目のcommitです。codeコマンドがPATHにない場合は、VS Codeのヘルプ → バージョン情報でも確認できます。

私は最初、オンラインWindows側の版を基準に考えていました。しかしRemote-SSHを起動しているのはRDP先です。真ん中のWindowsの版とcommitを見ないと、Linux側へ別のServerを置くことになります。

3. 同じcommitのServerアーカイブを用意する

オンラインWindowsで、Remote-SSHログに出たserver download URLと同じアーカイブを取得します。Linux x64の例では、次の形式のURLがログに出ます。

https://update.code.visualstudio.com/commit:<commit>/server-linux-x64/stable

ここはURLを手入力で決め打ちするより、ログに表示されたURLとアーキテクチャを使うほうが安全です。版によってserver-linux-x64ではなくCLI系のアーカイブが使われることがあります。

アーカイブをオフラインWindowsへ移したら、Linuxへ転送します。

scp .\vscode-server-linux-x64.tar.gz linux-user@linux-host:/tmp/

4. Linux側へServerを展開する

LinuxへSSHで入り、接続元で確認したcommitを指定します。

COMMIT="<code --versionの2行目>"
ARCHIVE="/tmp/vscode-server-linux-x64.tar.gz"
SERVER_ROOT="$HOME/.vscode-server/bin/$COMMIT"

mkdir -p "$SERVER_ROOT"
tar -xzf "$ARCHIVE" -C "$SERVER_ROOT" --strip-components=1
test -x "$SERVER_ROOT/bin/code-server" && echo "server OK"

最後にserver OKが出ることを確認します。出なければ、展開先の階層が一段ずれていないかを先に見ます。

find "$HOME/.vscode-server" -maxdepth 6 -type f -name code-server -print

server.shがなくても、すぐに展開失敗と決めない

古い手順ではserver.shを確認する例がありますが、私の1.111.0環境で本体として確認できたのはbin/code-serverでした。server.shがないこと自体は、壊れている証拠になりません。

ファイル名だけで判断せず、Remote-SSHログが探しているパスと、実際に展開された実行ファイルを照らし合わせるほうが確実でした。

5. Exec Server側の配置先も確認する

~/.vscode-server/bin/<commit>に置いてもRemote-SSHが再びダウンロードへ進むため、ログを追うとcli/servers/Stable-<commit>側を見ていました。

VS Code Server本体とExec Server側の2つの配置先を示す図
私の環境ではServer本体に加え、Exec Server側にも同じcommitの一式が必要でした。

私の環境では、次のように同じServer一式を配置しました。すでにserverディレクトリがある場合は、中途半端な展開物を上書きせず、内容とログを確認してから作業してください。

COMMIT="<code --versionの2行目>"
SERVER_ROOT="$HOME/.vscode-server/bin/$COMMIT"
CLI_ROOT="$HOME/.vscode-server/cli/servers/Stable-$COMMIT/server"

mkdir -p "$CLI_ROOT"
cp -a "$SERVER_ROOT/." "$CLI_ROOT/"
test -x "$CLI_ROOT/bin/code-server" && echo "exec server OK"

この2つ目のパスは、すべての版で必ず必要だと言い切れるものではありません。公式のトラブルシューティングでも、remote.SSH.useExecServerの状態によってServerログの場所が変わると説明されています。私の環境ではここが実際に効いた、という位置づけです。

切り分けのためにremote.SSH.useExecServerを一時的にfalseへ変える方法もあります。ただし、設定を何個も同時に変えると原因が分からなくなります。変更は一つずつ行い、Remote-SSHログの変化を確認しました。

6. 成功したときのログを確認する

再接続後、Remote-SSHログで次の流れになればServer側は通っています。

Using commit id "<接続元と同じcommit>"
Found existing installation at /home/<user>/.vscode-server...
Remote server is listening on port <port>

まだダウンロードを始める場合は、次の順で見直します。

  1. 接続元を取り違えていないか
  2. commitが完全一致しているか
  3. LinuxへSSHログインしているユーザーの$HOMEへ置いたか
  4. アーカイブのCPUアーキテクチャが合っているか
  5. bin/<commit>とcli/servers/Stable-<commit>のどちらをログが見ているか

7. パスワード入力が残るならauthorized_keysは別に直す

Serverが起動しても、接続のたびにパスワードを聞かれる場合はSSH鍵認証の問題です。私はauthorized_keysをauthorizes_keysと書き間違え、しかもファイルではなくディレクトリを作っていました。

まず種類と権限を確認します。

ls -ld "$HOME/.ssh"
file "$HOME/.ssh/authorized_keys"
ls -l "$HOME/.ssh/authorized_keys"

通常は~/.sshがディレクトリ、authorized_keysがファイルです。一般的な権限は次のとおりです。

mkdir -p "$HOME/.ssh"
touch "$HOME/.ssh/authorized_keys"
chmod 700 "$HOME/.ssh"
chmod 600 "$HOME/.ssh/authorized_keys"

綴りの違うディレクトリを見つけても、すぐ削除せず、中身がないことを確認してから整理します。Remote-SSHのServer配置とSSH鍵認証は別問題なので、同時に直そうとしないほうが追いやすいです。

今ならこの順番で確認する

オフライン環境でRemote-SSH接続前に確認する4項目の図
commit、SSH単体、Server配置、ログの順に確認すると、問題を混ぜずに追えます。

最初は「Linux側への展開に失敗した」と思い込み、同じ場所を何度も見ていました。実際にずれていたのは、どのWindowsが接続元なのかと、そのcommitのServerをRemote-SSHがどこで探しているかでした。

通常のSSH、commit、Server配置、Remote-SSHログの順に分けると、Failed to download VS Code Serverはかなり追いやすくなります。VS Codeを更新するとcommitも変わるため、以前つながったServerをそのまま使えるとは限りません。更新後に再発したら、まずcode --versionから確認します。

参考にした公式情報

スポンサーリンク

コメント

タイトルとURLをコピーしました