昨日まで普通に接続できていたはずのリモートへ、VS Code の Remote‑SSH で入ろうとしたら「Opening Remote Server…」のまま進まず、しばらくすると何度もパスワードの再入力を求められる——。端末からは同じ資格情報でログインできるのに VS Code だけ失敗する。この“再認証ループ”は、特定条件で発生しやすい既知の不具合と環境要因が重なることで起きます。本記事では、最短で復旧する実践手順から原因の深掘り、恒久対策までを一気に解説します。
症状と前提
- Remote‑SSH で接続時、Opening Remote Server… → Downloading VS Code Server… まで進むが完了しない。
- 数十秒〜数分おきにパスワード入力ダイアログが繰り返し表示される(成功しない)。
- 同じユーザーで
sshコマンドならログインできる。 - サーバー側の
~/.vscode-serverを削除しても改善しない。 - VS Code 本体は更新していない/Remote‑SSH 拡張は自動更新の可能性あり。
結論から先に述べると、Remote‑SSH が VS Code Server のダウンロード/初期化に失敗したまま再認証に戻ってしまう既知不具合と、ローカル/exec サーバー経由の起動挙動が噛み合わないことが主因となるケースが多いです。
最短の復旧手順(結論)
もっとも再現性高く解消する回避策は、以下 2 設定を無効化して再接続することです。
{
// settings.json へ追記
"remote.SSH.useLocalServer": false,
"remote.SSH.useExecServer": false
}
- GUI 操作:Ctrl + ,(環境設定) → 検索に
useLocalServer/useExecServerと入力 → チェックをオフ → 再接続。 - 再接続前に、サーバー側の
~/.vscode-serverと、クライアント側の Remote 関連キャッシュを一度クリーンにしておくと成功率が上がります(後述)。
この 2 設定の無効化により、VS Code がローカル側の補助プロセス(Local Server/Exec Server)経由でトンネルやコマンドを中継する挙動を避け、より単純な接続パスになります。結果として、再認証ループから抜けやすくなります。
なぜ起こるのか:仕組みと失敗点を理解する
Remote‑SSH と VS Code Server の関係
Remote‑SSH は、接続先ホスト上に ~/.vscode-server/bin/<commit-hash> を展開し、そこから VS Code Server(Node.js ベースの常駐コンポーネント)を起動します。初回接続や VS Code 本体の更新後は、このサーバーのダウンロード→展開→起動→ハンドシェイクが必要です。
再認証ループになりやすい典型パターン
- ダウンロードの途中でネットワークが遮断/タイムアウトし、再試行のたびに認証だけが繰り返される。
- サーバー側の
tmpやホームディレクトリがnoexecマウント/権限不備で、展開後に実行できず失敗。 - Local Server/Exec Server 利用時のポート転送やプロセス間通信が OS/ファイアウォール/ウイルス対策で阻害される。
- 拡張の特定バージョンで初期化順序が不安定になり、認証状態が維持されない。
このため、設定で Local/Exec サーバーを無効化し、展開場所と実行権限、ネットワーク到達性を整えるだけで改善することが多いのです。
チェックリスト:原因切り分けの順番
| 観点 | 確認方法 | 対処の要点 |
|---|---|---|
| リモートの外部到達性 | curl -I https://code.visualstudio.com/ などで外部に届くか確認(プロキシ経由なら環境変数も確認)。 | プロキシ設定(HTTP_PROXY/HTTPS_PROXY)や no_proxy を正しく設定。 |
| 一時領域の実行可否 | mount | grep noexec, umask, df -h | 実行不可領域なら TMPDIR を実行可能なディレクトリに、または remote.SSH.serverInstallPath を指定。 |
| 権限・SELinux | ls -ld ~/.vscode-server, getenforce | 所有者・実行権限を修正。SELinux が Enforcing なら適切なコンテキスト付与。 |
| 拡張/本体のバージョン | 拡張の更新履歴・本体のコミットハッシュを確認。 | 最新版へ更新、または直前に動いていた版へダウングレードして検証。 |
| Windows の中間ブロック | ファイアウォールの履歴、エンドポイント保護のログ、企業プロキシのルール。 | node.exe/code.exe のアウトバウンドを許可。企業環境は管理者へ例外申請。 |
| SSH 設定 | ssh -vvv user@host | 多要素認証・再鍵交換タイミングで切断していないか、ServerAliveInterval 等の調整。 |
ステップバイステップ:確実に復旧させる手順
1) ログを開いて症状を確定する
- VS Code コマンドパレット → Remote‑SSH: Show Log。
- 末尾付近にある Install VS Code Server の SSH 実行コマンドやエラー行を確認。
# 例:ログに出るインストールコマンド(抜粋・ダミー)
ssh -T user@host "uname && mkdir -p ~/.vscode-server/bin/xxxx && ... && tar -xzf - -C ~/.vscode-server/bin/xxxx"
2) Local/Exec サーバーを無効化
前掲の 2 設定を false に。再接続して改善するかを確認します。
3) キャッシュと残骸をクリーンにする
- サーバー側:
rm -rf ~/.vscode-server - クライアント側:
- Windows:
%APPDATA%\Code\User\globalStorage\配下の vscode-remote 関連を削除 - macOS / Linux:
~/.config/Code/User/globalStorage/の Remote 関連を削除
- Windows:
- VS Code 再起動 → 再接続
4) ネットワーク要件を満たしているか確認
# 外部に出られるか(企業プロキシ環境は要設定)
curl -I https://update.code.visualstudio.com/
# 必要なら一時的にプロキシ指定
export HTTPS_PROXY=http://proxy.example.com:8080
export HTTP_PROXY=http://proxy.example.com:8080
export NO_PROXY=localhost,127.0.0.1,.example.com
5) 手動インストールで「サーバー展開」だけ先に成功させる
ログに表示された Install VS Code Server のコマンドをコピーし、VS Code 外の端末から実行します。終わったら ~/.vscode-server/bin/<commit-hash> が作成されているか確認してください。
6) 実行不可マウント/権限の問題を解消
# 実行不可(noexec)なマウントがないか
mount | grep noexec
# 一時ディレクトリが実行不可なら TMPDIR を変更して再接続
mkdir -p ~/tmp_exec
export TMPDIR=~/tmp_exec
# 既存サーバーフォルダの権限
chmod -R u+rwX ~/.vscode-server
必要に応じて VS Code の remote.SSH.serverInstallPath に、実行可能なパス(例:~/apps/vscode-server)を指定します。
7) それでも駄目な場合:バージョンを揃えて検証
- VS Code 本体:安定版の最新へ更新、または直前に正常だった版に戻す。
- Remote‑SSH 拡張:最新へ更新。改善しない場合は直前の版へロールバック。
8) SSH 側で接続の安定性を上げる(恒久対策)
# ~/.ssh/config の例
Host my-remote
HostName remote.example.com
User devuser
Port 22
ServerAliveInterval 30
ServerAliveCountMax 5
PreferredAuthentications publickey,password
PubkeyAuthentication yes
TCPKeepAlive yes
IdentitiesOnly yes
多要素認証や定期的な再鍵交換で一時的に無応答になる環境では、上記の ServerAlive* で切断を避けられます。
トラブルの実例と復旧パターン
ケースA:企業プロキシ配下でダウンロード失敗 → 再認証
症状:ログに download failed や ECONNRESET。
対処:プロキシ環境変数を設定し、手動インストールで先に展開。Local/Exec サーバーは無効化。
ケースB:ホームが NFS マウント(noexec)
症状:展開はされるが起動時に実行権限エラー。
対処:TMPDIR をローカルディスクへ、または remote.SSH.serverInstallPath を別領域へ。
ケースC:Windows のエンドポイント保護が node.exe を遮断
症状:useLocalServer 有効時のみ失敗。
対処:node.exe(VS Code 同梱)と code.exe のアウトバウンド許可を追加。2 設定を false にして回避。
ケースD:拡張の更新直後からのみ再現
症状:特定コミットの VS Code Server 展開時に固まる。
対処:拡張のダウングレードで一時回避し、別の安定版に移行。恒久対策として「手動インストール+設定無効化」。
ログの読み方:どこを見れば原因が分かるか
Remote‑SSH のログには、以下のような要素が順に出力されます。エラーが出た直前の行を中心に確認してください。
- SSH 接続の確立(鍵/パスワード)
- OS 判定(
unameの結果) - VS Code Server の存在確認(既存の
~/.vscode-server/bin/<hash>) - ダウンロード/展開コマンドの実行
- サーバープロセス起動とポート/ソケットのバインド
- クライアントとのハンドシェイク
# 典型的な失敗メッセージ例(ダミー)
[12:34:56.789] Downloading VS Code Server failed: request to https://... timed out
[12:34:56.790] Resolver error: Error: The VS Code Server failed to start
[12:34:56.791] Password prompts from ssh repeated, giving up
タイムアウト系ならネットワーク、Permission denied や exec format error は権限/noexec、address already in use はポート競合です。
設定リファレンス:効果と副作用
| 設定キー | 推奨値 | 効果 | 副作用・注意 |
|---|---|---|---|
remote.SSH.useLocalServer | false | ローカル補助プロセスを使わずシンプルな経路で接続。 | マルチウィンドウ間での接続共有が減り、接続確立がやや遅くなる場合あり。 |
remote.SSH.useExecServer | false | Exec Server を使った制御を無効化。初期化の不安定要因を低減。 | 一部の最適化が効かなくなる可能性。 |
remote.SSH.serverInstallPath | 任意(例:~/apps/vscode-server) | サーバー展開先を明示して noexec や容量不足を回避。 | 指定先のバックアップや権限管理が必要。 |
remote.SSH.showLoginTerminal | true(調査時) | ログインシェルの表示で、環境変数やプロファイルの影響を観察。 | 平常運用ではノイズになるため解決後は false 推奨。 |
セキュリティとガバナンス観点の注意点
- 企業プロキシ・SSL インスペクション環境では、VS Code Server ダウンロード先の証明書が書き換えられ、検証に失敗する場合があります。信頼ストアの調整が必要です。
- 多要素認証(例:キーボードインタラクティブ+ワンタイムパス)では、VS Code 側のプロンプト制御と相性が悪いことがあり、
PreferredAuthenticationsを publickey 優先にすることで安定する例が見られます。 - サーバーの umask が厳しすぎる(
077など)と、展開物の実行ビットやディレクトリ実行権が落ちることがあります。展開時のみ一時的に緩めるか、権限修正を実施してください。
Windows / macOS / Linux それぞれの要点
Windows クライアント
- ファイアウォールで
code.exe/node.exeのアウトバウンド許可を確認。 - 社内セキュリティ製品のリアルタイム保護の一時停止や例外登録で改善する場合あり。
- PowerShell の実行ポリシーは無関係だが、プロファイルでプロキシ環境変数を設定していると影響します。
macOS クライアント
- Gatekeeper によるブロックは通例発生しないが、VPN 切替時のルーティングに注意。
- キーチェーン経由のパスワード保存で古い資格情報が残っている場合は削除して再保存。
Linux クライアント
- OpenSSH クライアントのバージョン差異で鍵アルゴリズム既定が異なることがあるため、
HostKeyAlgorithmsやKexAlgorithmsを明示すると安定。 - systemd‑resolved と VPN の並存で DNS が不安定なときは
/etc/hostsへのホスト名登録で一時回避。
よくある質問(FAQ)
サーバー側にインターネット接続がありません。どうすれば?
クライアント側で VS Code Server のアーカイブを取得し、SCP で ~/.vscode-server/bin/<commit-hash> に配置 → 所有権と権限を付与 → 起動できることを確認します。インストールコマンドはログに出るため、それを“手動で”実行するのが確実です。
鍵認証でもパスワード再入力が出るのはなぜ?
鍵認証は成功していても、VS Code Server 起動後のハンドシェイクで失敗すると、拡張側のリトライにより再度認証フローが走ります。鍵自体の問題ではないため、本記事の回避策(Local/Exec サーバー無効化や手動展開)を優先してください。
毎回ダウンロードがやり直される
ハッシュに対応するディレクトリが作成されても、権限や noexec によって実行に失敗 → 再ダウンロードになることがあります。serverInstallPath の指定で安定します。
復旧後のベストプラクティス(再発防止)
- 設定を固定:安定したら
remote.SSH.useLocalServer=false/useExecServer=falseをチーム標準に。 - インストール先を固定:
remote.SSH.serverInstallPathを共有ドキュメントで明示。 - ネットワーク健全性の監視:VPN/プロキシ切替時に DNS と到達性の簡易ヘルスチェックを行うスクリプトを用意。
- バージョン管理:VS Code 本体と拡張は、検証済みバージョンをチームで足並みを揃えて更新。
コピペ用:推奨設定と調査ワンライナー集
settings.json(安定運用テンプレート)
{
"remote.SSH.useLocalServer": false,
"remote.SSH.useExecServer": false,
"remote.SSH.serverInstallPath": "~/apps/vscode-server",
"remote.SSH.showLoginTerminal": false,
"remote.SSH.enableAgentForwarding": false
}
サーバー健全性チェック
# 回線・DNS
ping -c 3 code.visualstudio.com || echo "DNS/外部到達性に問題の可能性"
# ディスク・権限
df -h ~ ; umask ; id ; getenforce 2>/dev/null || true
# noexec の有無
mount | grep -E "noexec|nodev|nosuid" || echo "問題になるマウントオプションなし"
# VS Code Server 痕跡
ls -ld ~/.vscode-server ~/.vscode-server/bin/* 2>/dev/null || echo "未展開"
まとめ:まずは「2 設定オフ」で抜け出す
Remote‑SSH の「Opening Remote Server…」から進まず、パスワード再入力を促され続ける現象は、VS Code Server のダウンロード/初期化失敗が引き金になるケースが多数です。remote.SSH.useLocalServer=false と remote.SSH.useExecServer=false を適用し、キャッシュクリア・手動インストール・実行権限の確認を組み合わせれば、ほとんどの環境で短時間に復旧できます。再発防止には、展開先の固定とネットワーク/バージョンの統制が有効です。
付録:トラブル対応フローチャート(テキスト版)
再認証ループ発生
└─> settings.json で useLocalServer/ useExecServer を false → 再接続
├─> OK:解決
└─> NG:
├─> サーバー/クライアントの Remote キャッシュ削除 → 再接続
│ ├─> OK:解決
│ └─> NG:
├─> ネット到達性とプロキシ確認(curl/ping)→ 手動インストールを実施
│ ├─> OK:解決
│ └─> NG:
├─> noexec/権限/SELinux を確認 → serverInstallPath/TMPDIR 調整
│ ├─> OK:解決
│ └─> NG:
├─> 拡張/本体のバージョンを変更(更新 or ロールバック)
│ ├─> OK:解決
│ └─> NG:
└─> SSH 詳細ログ(-vvv)と Remote‑SSH ログでエラーパターン特定

コメント