💻 6月3日の MS Build で開催される VS Code Live に参加しましょう。

リモート開発のヒントとコツ

この記事では、Visual Studio Code のRemote Development拡張機能のトラブルシューティングのヒントとコツを説明します。各拡張機能の設定と使用方法については、SSH、Containers、WSLの記事を参照してください。または、リモート環境ですぐに作業を開始するのに役立つ入門チュートリアルを試してください。

GitHub Codespacesに関するヒントと質問については、GitHub Codespaces のドキュメントを参照してください。

SSHのヒント

SSHは強力で柔軟ですが、その分セットアップが複雑になります。このセクションでは、さまざまな環境でRemote - SSH拡張機能をセットアップして実行するためのヒントとコツを紹介します。

AIチャット応答のカスタマイズ

カスタム指示を使用すると、特定のコーディングプラクティスや技術スタックに合致する応答を得るために、一般的なガイドラインやルールを記述できます。

カスタム指示を使用して、接続しているリモート環境の種類（どのような言語やツールチェーンがインストールされているかなど）についてCopilotに詳細な情報を提供できます。ローカルで使用するのと同じようにcopilot-instructions.mdファイルを使用できます。開発コンテナを使用する場合にも、追加の指示設定手順があります。

$EDITOR変数の構成

macOS / Linux のリモートホストの場合、このスニペットをシェル設定ファイル（.bashrcや.zshrcなど）に追加します。

if [ "$VSCODE_INJECTION" = "1" ]; then
    export EDITOR="code --wait" # or 'code-insiders' if you're using VS Code Insiders
fi

Windows ホストの場合、同等のPowerShellは以下のとおりです。

if ($env:VSCODE_INJECTION -eq "1") {
    $env:EDITOR = "code --wait"  # or 'code-insiders' for VS Code Insiders
}

これで、git commitのように$EDITOR変数を使用するターミナルコマンドを実行すると、デフォルトのターミナルベースエディター（vimやnanoなど）の代わりにVS Codeでファイルが開かれます。

キーベース認証の構成

SSH公開鍵認証は、ローカルの「秘密」鍵とSSHホスト上のユーザーアカウントに関連付けられた「公開」鍵を組み合わせた、便利でセキュリティの高い認証方法です。このセクションでは、これらの鍵を生成し、ホストに追加する方法を説明します。

ヒント: Windows版PuTTYはサポート対象クライアントではありませんが、PuTTYGenで生成した鍵を変換することはできます。

クイックスタート: SSHキーの使用

リモートホストのSSHキーベース認証を設定します。まずキーペアを作成し、次に公開キーをホストにコピーします。

ローカルSSHキーペアの作成

ローカルマシンにSSHキーがすでに存在するか確認してください。これは通常、macOS / Linuxでは~/.ssh/id_ed25519.pubに、Windowsではユーザープロファイルフォルダ内の.sshディレクトリ（例: C:\Users\your-user\.ssh\id_ed25519.pub）にあります。

キーがない場合は、ローカルターミナル / PowerShell で以下のコマンドを実行してSSHキーペアを生成してください。

ssh-keygen -t ed25519 -b 4096

ヒント: ssh-keygenがありませんか？サポートされているSSHクライアントをインストールしてください。

秘密鍵ファイルのアクセス許可を制限する

  • macOS / Linux の場合、必要に応じて秘密鍵へのパスを置き換えて、以下のシェルコマンドを実行します。

    chmod 400 ~/.ssh/id_ed25519

  • Windowsの場合、PowerShellで以下のコマンドを実行し、ユーザー名に明示的な読み取りアクセスを許可します。

    icacls "privateKeyPath" /grant <username>:R

    その後、Windowsエクスプローラーで秘密鍵ファイルに移動し、右クリックしてプロパティを選択します。セキュリティタブ > 詳細設定 > 継承を無効にする > このオブジェクトから継承されたすべてのアクセス許可を削除を選択します。

macOSまたはLinuxマシンが接続できるように認証する

ローカルターミナルウィンドウで、ユーザー名とホスト名を適切に置き換えて、以下のコマンドのいずれかを実行し、ローカルの公開鍵をSSHホストにコピーします。

  • macOSまたはLinux SSHホストへの接続

    export USER_AT_HOST="your-user-name-on-host@hostname"
export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub"

ssh-copy-id -i "$PUBKEYPATH" "$USER_AT_HOST"

  • Windows SSHホストへの接続

    • ホストはOpenSSH Serverを使用しており、ユーザーは管理者グループに属しています。

      export USER_AT_HOST="your-user-name-on-host@hostname"
export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub"

ssh $USER_AT_HOST "powershell Add-Content -Force -Path \"\$Env:PROGRAMDATA\\ssh\\administrators_authorized_keys\" -Value '$(tr -d '\n\r' < "$PUBKEYPATH")'"

    • それ以外の場合

      export USER_AT_HOST="your-user-name-on-host@hostname"
export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub"

ssh $USER_AT_HOST "powershell New-Item -Force -ItemType Directory -Path \"\$HOME\\.ssh\"; Add-Content -Force -Path \"\$HOME\\.ssh\\authorized_keys\" -Value '$(tr -d '\n\r' < "$PUBKEYPATH")'"

      SSHホスト上のリモートユーザーの.sshフォルダにあるauthorized_keysファイルがあなたによって所有されており、他のユーザーがアクセスする許可を持っていないことを検証することをお勧めします。詳細については、OpenSSH wikiを参照してください。

Windowsマシンが接続できるように認証する

ローカルのPowerShellウィンドウで、ユーザー名とホスト名を適切に置き換えて、以下のコマンドのいずれかを実行し、ローカルの公開鍵をSSHホストにコピーします。

  • macOSまたはLinux SSHホストへの接続

    $USER_AT_HOST="your-user-name-on-host@hostname"
$PUBKEYPATH="$HOME\.ssh\id_ed25519.pub"

$pubKey=(Get-Content "$PUBKEYPATH" | Out-String); ssh "$USER_AT_HOST" "mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '${pubKey}' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

  • Windows SSHホストへの接続

    • ホストはOpenSSH Serverを使用しており、ユーザーは管理者グループに属しています。

      $USER_AT_HOST="your-user-name-on-host@hostname"
$PUBKEYPATH="$HOME\.ssh\id_ed25519.pub"

Get-Content "$PUBKEYPATH" | Out-String | ssh $USER_AT_HOST "powershell `"Add-Content -Force -Path `"`$Env:PROGRAMDATA\ssh\administrators_authorized_keys`" `""

    • それ以外の場合

      $USER_AT_HOST="your-user-name-on-host@hostname"
$PUBKEYPATH="$HOME\.ssh\id_ed25519.pub"

Get-Content "$PUBKEYPATH" | Out-String | ssh $USER_AT_HOST "powershell `"New-Item -Force -ItemType Directory -Path `"`$HOME\.ssh`"; Add-Content -Force -Path `"`$HOME\.ssh\authorized_keys`" `""

      SSHホスト上のリモートユーザーの.sshフォルダにあるauthorized_keysファイルがあなたによって所有されており、他のユーザーがアクセスする許可を持っていないことを検証してください。詳細については、OpenSSH wikiを参照してください。

専用キーでセキュリティを向上させる

すべてのSSHホストで単一のSSHキーを使用することは便利ですが、誰かが秘密鍵にアクセスすると、すべてのホストにもアクセスできるようになります。これを防ぐには、開発ホスト用に別のSSHキーを作成します。以下の手順に従ってください。

  1. 別のファイルに別のSSHキーを生成します。

    macOS / Linux: ローカルターミナルで以下のコマンドを実行します。

    ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519-remote-ssh

    Windows: ローカルPowerShellで以下のコマンドを実行します。

    ssh-keygen -t ed25519 -f "$HOME\.ssh\id_ed25519-remote-ssh"

  2. クイックスタートと同じ手順でSSHホスト上のキーを認証しますが、PUBKEYPATHをid_ed25519-remote-ssh.pubファイルに設定します。

  3. VS Codeで、コマンドパレット（F1）からRemote-SSH: 設定ファイルを開く...を実行し、SSH設定ファイルを選択して、次のようにホストエントリを追加（または変更）します。

    Host name-of-ssh-host-here
    User your-user-name-on-host
    HostName host-fqdn-or-ip-goes-here
    IdentityFile ~/.ssh/id_ed25519-remote-ssh

    ヒント: Windowsパスにも/を使用できます。\を使用する場合は、スラッシュを2つ使用する必要があります。例えば、C:\\path\\to\\my\\id_ed25519。

PuTTYGenで生成されたキーの再利用

接続先のホスト用にPuTTYGenを使用してSSH公開鍵認証を設定した場合、他のSSHクライアントが使用できるように秘密鍵を変換する必要があります。これを行うには

  1. ローカルでPuTTYGenを開き、変換したい秘密鍵を読み込みます。

  2. アプリケーションメニューから変換 > OpenSSHキーのエクスポートを選択します。変換されたキーを、ユーザープロファイルフォルダ内の.sshディレクトリのローカルの場所に保存します（例: C:\Users\youruser\.ssh）。

  3. この新しいローカルファイルがあなたによって所有されており、他のユーザーがアクセスする許可を持っていないことを検証してください。

  4. VS Codeで、コマンドパレット（F1）からRemote-SSH: 設定ファイルを開く...を実行し、変更したいSSH設定ファイルを選択して、次のようにホストエントリをconfigファイルに追加（または変更）してファイルを参照させます。

    Host name-of-ssh-host-here
    User your-user-name-on-host
    HostName host-fqdn-or-ip-goes-here
    IdentityFile ~/.ssh/exported-keyfile-from-putty

マルチユーザーサーバーのセキュリティを向上させる

Remote - SSH拡張機能は「VS Code Server」をインストールし、維持します。サーバーはランダムに生成されたキーで起動され、サーバーへの新しい接続はすべてそのキーを提供する必要があります。キーはリモートのディスクに保存され、現在のユーザーのみが読み取ることができます。/versionには認証なしで利用できるHTTPパスが1つあります。

デフォルトでは、サーバーはランダムなTCPポートでlocalhostをリッスンし、そのポートがローカルマシンに転送されます。LinuxまたはmacOSホストに接続している場合、特定のユーザーにロックダウンされたUnixソケットを使用するように切り替えることができます。このソケットがポートの代わりに転送されます。

注: この設定は接続多重化を無効にしますので、公開鍵認証の構成をお勧めします。

設定するには

  1. Windows、macOS、またはLinuxにローカルのOpenSSH 6.7+ SSHクライアントがあり、OpenSSH 6.7+ LinuxまたはmacOSホストがあることを確認してください（Windowsはこのモードをサポートしていません）。

  2. ローカルのVS Codeのユーザー設定でRemote.SSH: リモートサーバーのソケットリッスンを有効にするを有効にして、Remote - SSHをソケットモードに切り替えます。

    Listen on socket VS Code setting

  3. すでにSSHホストに接続している場合は、コマンドパレット（F1）からRemote-SSH: ホスト上のVS Codeサーバーを終了...を選択して、設定が有効になるようにします。

接続時にエラーが発生した場合は、SSHホストのsshd設定でソケット転送を有効にする必要がある場合があります。そのためには

  1. SSHホスト上（ローカルではない）で、テキストエディタ（vi、nano、picoなど）で/etc/ssh/sshd_configを開きます。
  2. AllowStreamLocalForwarding yes の設定を追加します。
  3. SSHサーバーを再起動します。（Ubuntuではsudo systemctl restart sshdを実行します）。
  4. 再試行してください。

ハングアップまたは失敗する接続のトラブルシューティング

VS Codeが接続中にハングアップしたり（そしてタイムアウトしたり）する問題が発生している場合、問題を解決するためにできることがいくつかあります。

一般的なトラブルシューティング: サーバーを削除する

さまざまなRemote-SSHの問題をトラブルシューティングするのに役立つコマンドの1つは、Remote-SSH: ホスト上のVS Codeサーバーを終了です。これによりサーバーが削除され、「server_nameへの接続を確立できませんでした: VS Codeサーバーの起動に失敗しました」のような、多くの問題やエラーメッセージを修正できます。

VS Codeがプロンプトを待機しているか確認する

VS Codeでremote.SSH.showLoginTerminalの設定を有効にして再試行してください。パスワードやトークンの入力を求められる場合は、プロンプトの頻度を減らす方法について代替SSH認証方法の有効化を参照してください。

それでも問題が解決しない場合は、settings.jsonに以下のプロパティを設定して再試行してください。

"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false

一部のWindows OpenSSHサーバーバージョンでのバグへの対応

特定のバージョンのWindows用OpenSSHサーバーのバグにより、ホストがWindowsを実行しているかを判断するデフォルトのチェックが正しく機能しない場合があります。これはWindows 1909以前に付属するOpenSSHサーバーでは発生しません。

幸いなことに、settings.jsonに以下を追加することで、SSHホストがWindowsを実行しているかどうかをVS Codeに明示的に伝えることで、この問題を回避できます。

"remote.SSH.useLocalServer": false

また、以下のプロパティを使用して、特定のホストをWindowsとしてVS Codeに強制的に認識させることもできます。

"remote.SSH.remotePlatform": {
    "host-in-ssh-config-or-fqdn": "windows"
}

修正がマージされたため、この問題はバージョン8.1.0.0より新しいサーバーで解決されるはずです。

リモートホストでTCP転送を有効にする

Remote - SSH拡張機能は、ホストとの通信を容易にするためにSSHトンネルを利用します。場合によっては、これがSSHサーバーで無効になっていることがあります。これが問題であるかどうかを確認するには、出力ウィンドウでRemote - SSHカテゴリを開き、以下のメッセージを確認してください。

open failed: administratively prohibited: open failed

そのメッセージが表示された場合は、以下の手順に従ってSSHサーバーのsshd設定を更新してください。

  1. SSHホスト上（ローカルではない）で、テキストエディタ（Vim、nano、Pico、Notepadなど）で/etc/ssh/sshd_configまたはC:\ProgramData\ssh\sshd_configを開きます。
  2. AllowTcpForwarding yes の設定を追加します。
  3. SSHサーバーを再起動します。（Ubuntuではsudo systemctl restart sshdを実行します。Windowsでは、管理者PowerShellでRestart-Service sshdを実行します）。
  4. 再試行してください。

SSH設定ファイルでProxyCommandパラメータを設定する

プロキシの背後にいてSSHホストに接続できない場合、ローカルのSSH設定ファイルでホストのProxyCommandパラメータを使用する必要があるかもしれません。使用例については、このSSH ProxyCommandの記事を参照してください。

リモートマシンがインターネットにアクセスできることを確認する

リモートマシンは、VS Code Serverと拡張機能をMarketplaceからダウンロードするためにインターネットアクセスが必要です。接続要件の詳細はFAQを参照してください。

リモートホストでHTTP_PROXY / HTTPS_PROXYを設定する

リモートホストがプロキシの背後にある場合、SSHホストでHTTP_PROXYまたはHTTPS_PROXY環境変数を設定する必要があるかもしれません。~/.bashrcファイルを開き、以下を追加してください（proxy.fqdn.or.ip:3128を適切なホスト名/IPとポートに置き換えてください）。

export HTTP_PROXY=http://proxy.fqdn.or.ip:3128
export HTTPS_PROXY=$HTTP_PROXY

# Or if an authenticated proxy
export HTTP_PROXY=http://username:password@proxy.fqdn.or.ip:3128
export HTTPS_PROXY=$HTTP_PROXY

noexecでマウントされた/tmpへの対処

一部のリモートサーバーは、/tmpからのスクリプト実行を禁止するように設定されています。VS Codeはインストールスクリプトをシステムのテンポラリディレクトリに書き込み、そこから実行しようとします。システム管理者と協力して、これを回避できるかどうかを判断できます。

インストール中に別のシェルが起動されるか確認する

一部のユーザーは、デフォルトとは異なるシェルを使用したいという理由で、SSHホスト上の.bash_profileまたは他の起動スクリプトから別のシェルを起動します。これはVS Codeのリモートサーバーインストールスクリプトを破損させる可能性があり、推奨されません。代わりに、リモートマシンでデフォルトシェルを変更するにはchshを使用してください。

接続ごとにマシンを動的に割り当てるシステムへの接続

一部のシステムでは、SSH接続が行われるたびに、SSH接続がクラスターから1つのノードに動的にルーティングされます。これはVS Codeにとって問題となります。なぜなら、リモートウィンドウを開くために2つの接続を行うからです。1つはVS Code Serverをインストールまたは起動するため（または既に実行中のインスタンスを見つけるため）、もう1つはVS Codeがサーバーと通信するために使用するSSHポートトンネルを作成するためです。VS Codeが2番目の接続を作成する際に別のマシンにルーティングされた場合、VS Codeサーバーと通信できなくなります。

この問題の回避策の1つは、OpenSSH（macOS/Linuxクライアントのみ）のControlMasterオプションを使用することです。これは代替SSH認証方法の有効化で説明されており、これによりVS Codeの2つの接続は、同じノードへの単一のSSH接続を介して多重化されます。

設定のヘルプについてはシステム管理者にお問い合わせください

SSHは非常に柔軟なプロトコルであり、多くの設定をサポートしています。ログインターミナルまたはRemote-SSH出力ウィンドウで他のエラーが表示される場合、それは設定の不足が原因である可能性があります。

SSHホストとクライアントに必要な設定については、システム管理者にお問い合わせください。SSHホストに接続するための特定のコマンドライン引数は、SSH設定ファイルに追加できます。

設定ファイルにアクセスするには、コマンドパレット（F1）からRemote-SSH: 設定ファイルを開く...を実行します。その後、管理者と協力して必要な設定を追加できます。

代替SSH認証方法の有効化

SSHリモートホストに接続していて、以下のいずれかの場合は

  • 2要素認証で接続している場合
  • パスワード認証を使用している場合
  • SSHエージェントが実行されていない、またはアクセスできない場合に、パスフレーズ付きのSSHキーを使用している場合

その場合、VS Codeは必要な情報の入力を自動的に促すはずです。プロンプトが表示されない場合は、VS Codeでremote.SSH.showLoginTerminalの設定を有効にしてください。この設定は、VS CodeがSSHコマンドを実行するたびにターミナルを表示します。ターミナルが表示されたら、認証コード、パスワード、またはパスフレーズを入力できます。

それでも問題が解決しない場合は、settings.jsonに以下のプロパティを追加して再試行する必要があるかもしれません。

"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false

macOSとLinuxを使用しており、パスワードやトークンを入力する頻度を減らしたい場合は、ローカルマシンでControlMaster機能を有効にして、OpenSSHが単一の接続で複数のSSHセッションを実行できるようにすることができます。

ControlMasterを有効にするには

  1. SSH設定ファイルに次のようなエントリを追加します。

    Host *
    ControlMaster auto
    ControlPath  ~/.ssh/sockets/%r@%h-%p
    ControlPersist  600

  2. 次に、mkdir -p ~/.ssh/socketsを実行してソケットフォルダを作成します。

SSHエージェントのセットアップ

パスフレーズ付きのキーを使用してSSHホストに接続する場合は、SSHエージェントがローカルで実行されていることを確認する必要があります。VS Codeは自動的にキーをエージェントに追加するため、リモートのVS Codeウィンドウを開くたびにパスフレーズを入力する必要がありません。

エージェントが実行されており、VS Codeの環境からアクセス可能であることを確認するには、ローカルのVS Codeウィンドウのターミナルでssh-add -lを実行します。エージェント内のキーのリスト（またはキーがないことを示すメッセージ）が表示されるはずです。エージェントが実行されていない場合は、これらの手順に従って起動してください。エージェントを起動した後、必ずVS Codeを再起動してください。

Windows

WindowsでSSHエージェントを自動的に有効にするには、ローカル管理者PowerShellを起動し、以下のコマンドを実行します。

# Make sure you're running as an Administrator
Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent

これで、ログイン時にエージェントが自動的に起動するようになります。

Linux

SSHエージェントをバックグラウンドで起動するには、以下を実行します。

eval "$(ssh-agent -s)"

ログイン時にSSHエージェントを自動的に起動するには、これらの行を~/.bash_profileに追加します。

if [ -z "$SSH_AUTH_SOCK" ]; then
   # Check for a currently running instance of the agent
   RUNNING_AGENT="`ps -ax | grep 'ssh-agent -s' | grep -v grep | wc -l | tr -d '[:space:]'`"
   if [ "$RUNNING_AGENT" = "0" ]; then
        # Launch a new instance of the agent
        ssh-agent -s &> .ssh/ssh-agent
   fi
   eval `cat .ssh/ssh-agent`
fi

macOS

エージェントはmacOSではデフォルトで実行されているはずです。

リモートでローカルSSHエージェントを利用できるようにする

ローカルマシン上のSSHエージェントは、Remote - SSH拡張機能が選択したリモートシステムにパスフレーズを繰り返し入力することなく接続することを可能にしますが、リモートで実行されるGitのようなツールは、ローカルでアンロックされた秘密鍵にアクセスできません。

これは、リモートで統合ターミナルを開き、ssh-add -lを実行することで確認できます。このコマンドはアンロックされたキーを一覧表示するはずですが、代わりに認証エージェントに接続できないというエラーを報告します。ForwardAgent yesを設定すると、ローカルSSHエージェントがリモート環境で利用可能になり、この問題を解決できます。

これを行うには、.ssh/configファイル（またはRemote.SSH.configFileが設定されているもの - 確実に確認するにはRemote-SSH: SSH設定ファイルを開く...コマンドを使用してください）を編集し、以下を追加します。

Host *
    ForwardAgent yes

特定の名前付きホストに対してのみオプションを設定して、より制限的にしたい場合があることに注意してください。

SSHファイルアクセス許可エラーの修正

SSHはファイルアクセス許可に厳格であり、誤って設定されている場合、「WARNING: UNPROTECTED PRIVATE KEY FILE!」などのエラーが表示されることがあります。これを修正するためにファイルアクセス許可を更新する方法はいくつかあり、以下のセクションで説明します。

ローカルSSHファイルとフォルダのアクセス許可

macOS / Linux

ローカルマシンで、以下のアクセス許可が設定されていることを確認してください。

フォルダ / ファイル アクセス許可
ユーザーフォルダ内の.ssh chmod 700 ~/.ssh
ユーザーフォルダ内の.ssh/config chmod 600 ~/.ssh/config
ユーザーフォルダ内の.ssh/id_ed25519.pub chmod 600 ~/.ssh/id_ed25519.pub
その他のキーファイル chmod 600 /path/to/key/file

Windows

期待される特定のアクセス許可は、使用しているSSH実装によって異なる場合があります。私たちは、標準のWindows 10 OpenSSHクライアントを使用することをお勧めします。

この場合、SSHホスト上のリモートユーザーの.sshフォルダ内のすべてのファイルがあなたによって所有されており、他のユーザーがアクセスする許可を持っていないことを確認してください。詳細については、Windows OpenSSH wikiを参照してください。

その他のクライアントについては、実装が期待する内容についてクライアントのドキュメントを参照してください。

サーバーSSHファイルとフォルダのアクセス許可

macOS / Linux

接続先のリモートマシンで、以下のアクセス許可が設定されていることを確認してください。

フォルダ / ファイル Linux / macOS アクセス許可
サーバー上のユーザーフォルダ内の.ssh chmod 700 ~/.ssh
サーバー上のユーザーフォルダ内の.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

現在、Linuxホストのみがサポートされており、そのためmacOSとWindows 10のアクセス許可は省略されていることに注意してください。

Windows

Windows OpenSSHサーバーの適切なファイルアクセス許可を設定する方法については、Windows OpenSSH wikiを参照してください。

サポートされているSSHクライアントのインストール

OS 指示
Windows 10 1803+ / Server 2016/2019 1803+ Windows OpenSSHクライアントをインストールします。
以前のWindows Git for Windowsをインストールします。
macOS プリインストールされています。
Debian/Ubuntu sudo apt-get install openssh-clientを実行します。
RHEL / Fedora / CentOS sudo yum install openssh-clientsを実行します。

VS CodeはPATHでsshコマンドを探します。見つからない場合、WindowsではデフォルトのGit for Windowsインストールパスでssh.exeを探そうとします。settings.jsonにremote.SSH.pathプロパティを追加することで、VS CodeにSSHクライアントの場所を具体的に伝えることもできます。

サポートされているSSHサーバーのインストール

OS 指示 詳細
Debian 8+ / Ubuntu 16.04+ sudo apt-get install openssh-serverを実行します。 詳細については、Ubuntu SSHのドキュメントを参照してください。
RHEL / CentOS 7+ sudo yum install openssh-server && sudo systemctl start sshd.service && sudo systemctl enable sshd.serviceを実行します。 詳細については、RedHat SSHのドキュメントを参照してください。
SuSE 12+ / openSUSE 42.3+ Yastでサービスマネージャーに移動し、リストから「sshd」を選択して有効にするをクリックします。次にファイアウォールに移動し、恒久設定を選択し、サービスの下でsshdをチェックします。 詳細については、SuSE SSHのドキュメントを参照してください。
Windows 10 1803+ / Server 2016/2019 1803+ Windows OpenSSHサーバーをインストールします。
macOS 10.14+ (Mojave) リモートログインを有効にします。

SSHホストでのGitプッシュまたは同期時のハングアップの解決

SSHを使用してGitリポジトリをクローンし、SSHキーにパスフレーズがある場合、リモートで実行するとVS Codeのプルおよび同期機能がハングアップする可能性があります。

パスフレーズなしのSSHキーを使用するか、HTTPSを使用してクローンするか、またはコマンドラインからgit pushを実行して問題を回避してください。

SSHFSを使用してリモートホスト上のファイルにアクセスする

SSHFSは、SFTPから構築された安全なリモートファイルシステムアクセスプロトコルです。CIFS / Samba共有のようなものと比較して、マシンへのSSHアクセスのみが必要であるという利点があります。

注: パフォーマンス上の理由から、SSHFSは単一ファイルの編集やコンテンツのアップロード/ダウンロードに最適です。一度に多くのファイルに大量に読み書きするアプリケーション（ローカルのソース管理ツールなど）を使用する必要がある場合、rsyncの方が適しています。

macOS / Linux:

Linuxでは、ディストリビューションのパッケージマネージャーを使用してSSHFSをインストールできます。Debian/Ubuntuの場合: sudo apt-get install sshfs

注: WSL 1はFUSEまたはSSHFSをサポートしていないため、現在Windowsの手順は異なります。WSL 2はFUSEとSSHFSのサポートを含んでいますので、これはまもなく変更される予定です。

macOSでは、Homebrewを使用してSSHFSをインストールできます。

brew install --cask macfuse
brew install gromgit/fuse/sshfs-mac
brew link --overwrite sshfs-mac

さらに、コマンドラインを使用してリモートファイルシステムをマウントしたくない場合は、SSHFS GUIをインストールすることもできます。

コマンドラインを使用するには、ローカルターミナルから以下のコマンドを実行します（user@hostnameをリモートユーザーとホスト名/IPに置き換えてください）。

export USER_AT_HOST=user@hostname
# Make the directory where the remote filesystem will be mounted
mkdir -p "$HOME/sshfs/$USER_AT_HOST"
# Mount the remote filesystem
sshfs "$USER_AT_HOST:" "$HOME/sshfs/$USER_AT_HOST" -ovolname="$USER_AT_HOST" -p 22  \
    -o workaround=nonodelay -o transform_symlinks -o idmap=user  -C

これにより、リモートマシンのホームフォルダが~/sshfsの下で利用可能になります。作業が終了したら、OSのFinder / ファイルエクスプローラーまたはコマンドラインを使用してアンマウントできます。

umount "$HOME/sshfs/$USER_AT_HOST"

Windows

次の手順を実行します。

  1. Linuxでは、LinuxとWindows間でCRLF/LFの違いによる予期しない問題を避けるために、プロジェクトに.gitattributesファイルを追加して、両OS間で一貫した行末を強制します。詳細については、Gitの改行コード問題の解決を参照してください。

  2. 次に、Chocolateyを使用してSSHFS-Winをインストールします: choco install sshfs

  3. Windows用のSSHFSをインストールしたら、ファイルエクスプローラーのネットワークドライブの割り当て...オプションをパス\\sshfs\user@hostname（ここでuser@hostnameはリモートユーザーとホスト名/IPです）と共に使用できます。これをコマンドプロンプトで次のようにスクリプト化できます: net use /PERSISTENT:NO X: \\sshfs\user@hostname

  4. 完了したら、ファイルエクスプローラーでドライブを右クリックし、切断を選択して切断します。

ターミナルからリモートホストに接続する

ホストが構成されたら、リモートURIを渡すことでターミナルから直接接続できます。

例えば、remote_serverに接続して/code/my_projectフォルダを開くには、以下を実行します。

code --remote ssh-remote+remote_server /code/my_project

入力されたパスがファイルなのかフォルダなのかについて、ある程度の推測が必要です。ファイル拡張子がある場合、それはファイルと見なされます。

フォルダを強制的に開くには、パスにスラッシュを追加するか、以下を使用します。

code --folder-uri vscode-remote://ssh-remote+remote_server/code/folder.with.dot

ファイルを強制的に開くには、--gotoを追加するか、以下を使用します。

code --file-uri vscode-remote://ssh-remote+remote_server/code/fileWithoutExtension

rsyncを使用してソースコードのローカルコピーを維持する

SSHFSを使用してリモートファイルにアクセスすることの代替案は、rsyncを使用して、リモートホスト上のフォルダの全内容をローカルマシンにコピーすることです。rsyncコマンドは、実行されるたびに更新が必要なファイルを決定するため、scpやsftpのようなものを使用するよりもはるかに効率的で便利です。これは、マルチファイルやパフォーマンス集約型のローカルツールを本当に使用する必要がある場合に主に検討すべきことです。

rsyncコマンドはmacOSでは標準で利用可能で、Linuxパッケージマネージャー（例: Debian/Ubuntuではsudo apt-get install rsync）を使用してインストールできます。Windowsの場合、このコマンドにアクセスするにはWSLまたはCygwinのいずれかを使用する必要があります。

コマンドを使用するには、同期されたコンテンツを保存したいフォルダに移動し、user@hostnameをリモートユーザーとホスト名/IPに、/remote/source/code/pathをリモートソースコードの場所に置き換えて以下を実行します。

macOS、Linux、またはWSL内

rsync -rlptzv --progress --delete --exclude=.git "user@hostname:/remote/source/code/path" .

またはWindows上のPowerShellからWSLを使用

wsl rsync -rlptzv --progress --delete --exclude=.git "user@hostname:/remote/source/code/path" "`$(wslpath -a '$PWD')"

このコマンドを、ファイルの最新コピーを取得したいときにいつでも再実行でき、更新のみが転送されます。.gitフォルダは、パフォーマンス上の理由と、リモートホストの状態を気にすることなくローカルのGitツールを使用できるようにするために、意図的に除外されています。

コンテンツをプッシュするには、コマンドのソースとターゲットのパラメータを逆にします。ただし、Windows上では、これを行う前にプロジェクトに.gitattributesファイルを追加して一貫した行末を強制する必要があります。詳細については、Gitの改行コード問題の解決を参照してください。

rsync -rlptzv --progress --delete --exclude=.git . "user@hostname:/remote/source/code/path"

リモート上のVS Code Serverをクリーンアップする

SSH拡張機能は、リモートマシンからVS Code Serverをクリーンアップするためのコマンド、Remote-SSH: ホストからVS Codeサーバーをアンインストール...を提供します。このコマンドは2つのことを行います。実行中のVS Code Serverプロセスをすべて終了させ、サーバーがインストールされていたフォルダを削除します。

これらの手順を手動で実行したい場合、またはコマンドが機能しない場合は、次のようなスクリプトを実行できます。

# Kill server processes
kill -9 $(ps aux | grep vscode-server | grep $USER | grep -v grep | awk '{print $2}')
# Delete related files and folder
rm -rf $HOME/.vscode-server # Or ~/.vscode-server-insiders

VS Code Serverは以前は~/.vscode-remoteの下にインストールされていたので、その場所も確認できます。

リモートWSL 2ホストへのSSH接続

SSHを使用してリモートマシンで実行されているWSLディストリビューションに接続したい場合があります。外部マシンからWindows 10上のBashおよびWSL 2にSSH接続する方法については、このガイドを参照してください。

問題の報告

Remote-SSH拡張機能の使用に問題があり、問題を報告する必要があると思われる場合は、まずこのサイトのドキュメントを読み、次にログファイルの取得方法や問題の原因を絞り込むのに役立つ追加手順については、トラブルシューティングのWikiドキュメントを参照してください。

Dev Containersのヒント

Dev Containersの使用に関するヒントを読みたい場合は、Dev Containersのヒントとコツをご覧ください。

WSLのヒント

初回起動: VS Code Serverの前提条件

一部のWSL Linuxディストリビューションには、VS Codeサーバーの起動に必要なライブラリが不足しています。パッケージマネージャーを使用して、Linuxディストリビューションに追加のライブラリを追加できます。

DebianとUbuntu

DebianまたはUbuntuのWSLシェルを開き、wgetとca-certificatesを追加します。

sudo apt-get update && sudo apt-get install wget ca-certificates

Alpine

ルートとしてAlpine WSLシェルを開き（wsl -d Alpine -u root）、libstdc++を追加します。

apk update && apk add libstdc++

Windows 10 April 2018 Update (ビルド1803) 以前では、/bin/bashが必要です。

apk update && apk add bash

WSL拡張機能で使用されるディストリビューションの選択

WSL: 新しいウィンドウは、デフォルトとして登録されているWSLディストリビューションを開きます。

デフォルト以外のディストリビューションを開くには、使用するディストリビューションのWSLシェルからcode .を実行するか、WSL: ディストリビューションを使用して新しいウィンドウを開くを使用します。

Windows 10 May 2019 Update (バージョン1903) より古いWSLバージョンでは、WSLコマンドはデフォルトのディストリビューションのみを使用できます。このため、WSL拡張機能はデフォルトのディストリビューションを変更することに同意するかどうかを尋ねる場合があります。

デフォルトを変更するには、いつでもwslconfig.exeを使用できます。

例えば

wslconfig /setdefault Ubuntu

インストールされているディストリビューションを確認するには、以下を実行します。

wslconfig /l

サーバー起動のための環境設定

WSL拡張機能がWSLでVS Codeサーバーを起動する際、いかなるシェル設定スクリプトも実行しません。これは、カスタム設定スクリプトが起動を妨げることを避けるために行われました。

起動環境を設定する必要がある場合は、こちらで説明されている環境設定スクリプトを使用できます。

リモート拡張機能ホストの環境設定

リモート拡張機能ホストとターミナルの環境は、デフォルトシェルの設定スクリプトに基づいています。リモート拡張機能ホストプロセスの環境変数を評価するために、サーバーはデフォルトシェルのインスタンスを対話型ログインシェルとして作成します。そこから環境変数をプローブし、それらをリモート拡張機能ホストプロセスの初期環境として使用します。したがって、環境変数の値は、デフォルトとして設定されているシェルと、そのシェルの設定スクリプトの内容に依存します。

各シェルの設定スクリプトの概要については、Unixシェル初期化を参照してください。ほとんどのWSLディストリビューションでは、/bin/bashがデフォルトシェルとして設定されています。/bin/bashは、最初に/etc/profileの下の起動ファイルを探し、次に~/.bash_profile、~/.bash_login、~/.profileの下の起動ファイルを探します。

WSLディストリビューションのデフォルトシェルを変更するには、このブログ記事の手順に従ってください。

codeコマンドが機能しない問題の修正

Windows上のWSLターミナルからcodeと入力してもcodeが見つからずに機能しない場合、WSLのPATHにいくつかの重要な場所が不足している可能性があります。

WSLターミナルを開き、echo $PATHと入力して確認してください。VS Codeのインストールパスが表示されるはずです。デフォルトでは、これは以下のようになります。

/mnt/c/Users/Your Username/AppData/Local/Programs/Microsoft VS Code/bin

ただし、システムインストーラーを使用した場合は、インストールパスは以下のようになります。

/mnt/c/Program Files/Microsoft VS Code/bin

...または...

/mnt/c/Program Files (x86)/Microsoft VS Code/bin

WSLの機能として、パスはWindowsのPATH変数から継承されます。WindowsのPATH変数を変更するには、Windowsのスタートメニューからアカウントの環境変数を編集コマンドを使用します。

パス共有機能を無効にしている場合は、.bashrcを編集し、以下を追加して新しいターミナルを起動します。

WINDOWS_USERNAME="Your Windows Alias"

export PATH="$PATH:/mnt/c/Windows/System32:/mnt/c/Users/${WINDOWS_USERNAME}/AppData/Local/Programs/Microsoft VS Code/bin"
# or...
# export PATH="$PATH:/mnt/c/Program Files/Microsoft VS Code/bin"
# or...
# export PATH="$PATH:/mnt/c/Program Files (x86)/Microsoft VS Code/bin"

注: ディレクトリ名にスペース文字がある場合は、引用符で囲むかエスケープしてください。

'code'コマンドの問題点の発見

Windowsのコマンドプロンプトからcodeと入力してもVS Codeが起動しない場合、VSCODE_WSL_DEBUG_INFO=true code .を実行することで問題の診断に役立てることができます。

問題を報告し、完全な出力を添付してください。

サーバーの起動または接続の問題の発見

WSLウィンドウがリモートサーバーへの接続に失敗した場合、WSLログで詳細情報を取得できます。問題を報告する際には、常にWSLログの全内容を送信することが重要です。

WSL: ログを開くコマンドを実行してWSLログを開きます。ログはターミナルビューのWSLタブに表示されます。

WSL Log

さらに詳細なログを取得するには、ユーザー設定でremote.WSL.debugの設定を有効にします。

サーバーがセグメンテーション違反で起動に失敗する

この問題の調査に役立てるために、コアダンプファイルを送信してください。コアダンプファイルを取得するには、以下の手順に従ってください。

Windowsコマンドプロンプトで

  • code --locate-extension ms-vscode-remote.remote-wslを実行してWSL拡張機能フォルダを特定します。
  • 返されたパスにcdします。
  • wslServer.shスクリプトをVS Codeで開きます。code .\scripts\wslServer.sh。
  • 最後の行（"$VSCODE_REMOTE_BIN/$COMMIT/bin/$SERVER_APPNAME" "$@"の前）の前に、ulimit -C unlimitedを追加します。
  • リモートサーバーを実行しているWSLウィンドウを起動し、セグメンテーション違反が発生するのを待ちます。

コアファイルは上記のWSL拡張機能フォルダにあります。

開いているワークスペース内のフォルダの名前を変更しようとすると、EACCES: permission denied エラーが表示されます。

これは、VS Codeによってアクティブになるファイルウォッチャーが原因で発生するWSLファイルシステム実装の既知の問題です（Microsoft/WSL#3395、Microsoft/WSL#1956）。この問題はWSL 2でのみ修正されます。

この問題を回避するには、remote.WSL.fileWatcher.pollingをtrueに設定します。ただし、ポーリングベースの場合、大規模なワークスペースではパフォーマンスに影響があります。

大規模なワークスペースの場合、ポーリング間隔remote.WSL.fileWatcher.pollingIntervalを増やし、監視対象フォルダを files.watcherExclude VS Codeで開く VS Code Insidersで開く で制御することをお勧めします。

WSL 2にはそのファイルウォッチャーの問題はなく、新しい設定の影響も受けません。

WSLでのGitの改行コード問題の解決（多数のファイルが変更されたと表示される問題）

WindowsとLinuxではデフォルトの改行コードが異なるため、Gitは改行コード以外の違いがないにもかかわらず、多数の変更されたファイルを報告する場合があります。これを防ぐには、.gitattributesファイルを使用するか、Windows側でグローバルに改行コード変換を無効にできます。

通常、リポジトリに.gitattributesファイルを追加または変更することが、この問題を解決する最も信頼性の高い方法です。このファイルをソース管理にコミットすることで、他のユーザーを助け、リポジトリごとに動作を適切に変えることができます。たとえば、リポジトリのルートに以下の.gitattributesファイルを追加すると、CRLFを必要とするWindowsバッチファイルを除いて、すべてをLFに強制します。

* text=auto eol=lf
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf

これはGit v2.10以降で動作することに注意してください。問題が発生している場合は、最新のGitクライアントがインストールされていることを確認してください。CRLFを必要とする他のファイルタイプもこの同じファイルに追加できます。

Unixスタイルの改行コード（LF）を常にアップロードしたい場合は、inputオプションを使用できます。

git config --global core.autocrlf input

改行コード変換を完全に無効にしたい場合は、代わりに以下を実行します。

git config --global core.autocrlf false

最後に、これらの設定が有効になるように、リポジトリを再度クローンする必要がある場合があります。

WindowsとWSLの間でGit認証情報を共有する

HTTPSを使用してリポジトリをクローンし、Windowsで認証情報ヘルパーを設定している場合、これをWSLと共有して、入力したパスワードが両側で永続化されるようにできます。（これはSSHキーの使用には適用されないことに注意してください。）

以下の手順に従ってください。

  1. WindowsコマンドプロンプトまたはPowerShellで以下を実行して、Windows上の認証情報マネージャーを設定します。

     git config --global credential.helper wincred

  2. 同じ認証情報ヘルパーを使用するようにWSLを設定しますが、WSLターミナルで以下を実行します。

     git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"

これで、Windows側でGitを操作する際に入力したパスワードはWSLで利用可能になり、その逆も同様です。

WSLからのGitプッシュまたは同期時のハングアップの解決

SSHを使用してGitリポジトリをクローンし、SSHキーにパスフレーズがある場合、リモートで実行するとVS Codeのプルおよび同期機能がハングアップする可能性があります。

パスフレーズなしのSSHキーを使用するか、HTTPSを使用してクローンするか、またはコマンドラインからgit pushを実行して問題を回避してください。

GitHub Codespacesのヒント

GitHub Codespacesに関するヒントと質問については、GitHub Codespacesのドキュメントを参照してください。また、Codespacesに影響を与える可能性のある既知のWeb制限と適応も確認できます。

拡張機能のヒント

多くの拡張機能は修正なしで動作しますが、特定の機能が期待どおりに動作しない原因となるいくつかの問題があります。場合によっては、別のコマンドを使用して問題を回避できますが、その他の場合は、拡張機能を変更する必要があるかもしれません。このセクションでは、一般的な問題とそれらを解決するためのヒントを簡単に紹介します。拡張機能をリモート拡張機能ホストをサポートするように変更するための詳細なガイドについては、リモート開発のサポートに関する主要な拡張機能の記事も参照できます。

依存関係の欠落に関するエラーの解決

一部の拡張機能は、特定のWSL Linuxディストリビューションの基本インストールでは見つからないライブラリに依存しています。パッケージマネージャーを使用して、Linuxディストリビューションに追加のライブラリを追加できます。UbuntuおよびDebianベースのディストリビューションの場合、sudo apt-get install <package>を実行して必要なライブラリをインストールします。追加のインストール詳細については、拡張機能のドキュメントまたはエラーメッセージで言及されているランタイムを確認してください。

リモート適用時にローカルの絶対パス設定が失敗する

リモートエンドポイントに接続すると、VS Codeのローカルユーザー設定が再利用されます。これによりユーザーエクスペリエンスの一貫性が保たれますが、ターゲットの場所が異なるため、ローカルマシンと各ホスト/コンテナ/WSLの間で絶対パスの設定を変える必要がある場合があります。

解決策: リモートエンドポイントに接続した後、コマンドパレット（F1）から基本設定: リモート設定を開くコマンドを実行するか、設定エディターでリモートタブを選択することで、エンドポイント固有の設定を行うことができます。これらの設定は、接続するたびに既存のローカル設定を上書きします。

リモートエンドポイントにローカルVSIXをインストールする必要がある

開発中または拡張機能の作者から修正を試すように依頼された場合など、リモートマシンにローカルVSIXをインストールしたい場合があります。

解決策: SSHホスト、コンテナ、またはWSLに接続した後、ローカルと同じ方法でVSIXをインストールできます。コマンドパレット（F1）から拡張機能: VSIXからインストール...コマンドを実行します。最新のMarketplaceバージョンへの自動更新を防ぐために、settings.jsonに"extensions.autoUpdate": falseを追加することもできます。リモート環境での拡張機能の開発とテストに関する詳細については、リモート開発のサポートを参照してください。

ブラウザがローカルで開かない

一部の拡張機能は、外部のNodeモジュールやカスタムコードを使用してブラウザウィンドウを起動します。残念ながら、これにより拡張機能がブラウザをローカルではなくリモートで起動してしまう可能性があります。

解決策: 拡張機能はvscode.env.openExternal APIを使用してこの問題を解決できます。詳細については、拡張機能作者ガイドを参照してください。

クリップボードが機能しない

一部の拡張機能は、clipboardyのようなNodeモジュールを使用してクリップボードと統合します。残念ながら、これにより拡張機能がリモート側でクリップボードと正しく統合できない可能性があります。

解決策: 拡張機能はVS CodeクリップボードAPIに切り替えることで問題を解決できます。詳細については、拡張機能作者ガイドを参照してください。

ブラウザまたはアプリケーションからローカルWebサーバーにアクセスできない

コンテナ、SSHホスト、またはGitHub Codespaces内で作業している場合、ブラウザが接続しようとしているポートがブロックされている可能性があります。

解決策: 拡張機能は、vscode.env.openExternalまたはvscode.env.asExternalUri API（localhostポートを自動的に転送します）を使用してこの問題を解決できます。詳細については、拡張機能作者ガイドを参照してください。回避策として、ポート転送コマンドを手動で実行してください。

Webviewのコンテンツが表示されない

拡張機能のWebViewコンテンツがiframeを使用してローカルWebサーバーに接続する場合、WebViewが接続しようとしているポートがブロックされている可能性があります。さらに、拡張機能がasWebviewUriを使用せずにvscode-resource:// URIをハードコードしている場合、Codespacesブラウザエディタでコンテンツが表示されない場合があります。

解決策: 拡張機能はwebview.asWebviewUriを使用して、vscode-resource:// URIに関する問題を解決できます。

ポートがブロックされている場合、最善のアプローチは代わりにwebviewメッセージパッシングAPIを使用することです。回避策として、vscode.env.asExternalUriを使用すると、webviewがVS Codeから起動されたlocalhost Webサーバーに接続できます。ただし、これは現在、Codespacesブラウザベースエディタ（のみ）ではMicrosoftDocs/vscodespaces#11によってブロックされています。回避策の詳細については、拡張機能作者ガイドを参照してください。

ブロックされたlocalhostポート

外部アプリケーションからlocalhostポートに接続しようとすると、ポートがブロックされる場合があります。

解決策: VS Code 1.40で、拡張機能が任意のポートをプログラムで転送するための新しいvscode.env.asExternalUri APIが導入されました。詳細については、拡張機能作者ガイドを参照してください。回避策として、ポート転送コマンドを手動で実行できます。

拡張機能データの保存エラー

拡張機能は、Linux上の~/.config/Codeフォルダを探してグローバルデータを永続化しようとすることがあります。このフォルダが存在しない場合、拡張機能がENOENT: そのようなファイルまたはディレクトリはありません, '/root/.config/Code/User/filename-goes-hereのようなエラーを発生させる可能性があります。

解決策: 拡張機能はcontext.globalStorageUriまたはcontext.storageUriプロパティを使用してこの問題を解決できます。詳細については、拡張機能作者ガイドを参照してください。

サインインできない / 新しいエンドポイントに接続するたびにサインインが必要

サインインを必要とする拡張機能は、独自のコードを使用してシークレットを永続化する場合があります。このコードは依存関係の欠落により失敗する可能性があります。成功したとしても、シークレットはリモートに保存されるため、新しいエンドポイントごとにサインインする必要があります。

解決策: 拡張機能はSecretStorage APIを使用してこの問題を解決できます。詳細については、拡張機能作者ガイドを参照してください。

互換性のない拡張機能がVS Codeの接続を妨げる

リモートホスト、コンテナ、またはWSLに互換性のない拡張機能がインストールされている場合、VS Code Serverが互換性のためにハングアップまたはクラッシュする事例が見られました。拡張機能がすぐにアクティブ化されると、接続できなくなり、拡張機能をアンインストールできなくなる可能性があります。

解決策: 以下の手順に従って、リモート拡張機能フォルダを手動で削除します。

  1. コンテナの場合、devcontainer.jsonに問題のある拡張機能への参照が含まれていないことを確認してください。

  2. 次に、別のターミナル/コマンドプロンプトを使用してリモートホスト、コンテナ、またはWSLに接続します。

    • SSHまたはWSLの場合、環境に適切に接続します（サーバーに接続するにはsshを実行するか、WSLターミナルを開きます）。
    • コンテナを使用している場合、docker ps -aを呼び出し、リストから正しい名前のイメージを探してコンテナIDを特定します。コンテナが停止している場合は、docker run -it <id> /bin/shを実行します。実行中の場合は、docker exec -it <id> /bin/shを実行します。

  3. 接続したら、VS Code Stableの場合はrm -rf ~/.vscode-server/extensionsを、VS Code Insidersの場合はrm -rf ~/.vscode-server-insiders/extensionsを実行して、すべての拡張機能を削除します。

事前にビルドされたネイティブモジュールを同梱または取得する拡張機能が失敗する

VS Code拡張機能にバンドルされている（または動的に取得される）ネイティブモジュールは、Electronのelectron-rebuildを使用して再コンパイルする必要があります。しかし、VS Code Serverは標準（非Electron）バージョンのNode.jsを実行するため、リモートで使用するとバイナリが失敗する可能性があります。

解決策: この問題を解決するには、拡張機能を変更する必要があります。VS Codeが提供するNode.jsの「モジュール」バージョンに対応する両方のバイナリセット（Electronおよび標準Node.js）を含める（または動的に取得する）必要があります。その後、アクティベーション関数でcontext.executionContext === vscode.ExtensionExecutionContext.Remoteであるかどうかを確認して、正しいバイナリを設定します。詳細については、拡張機能作者ガイドを参照してください。

拡張機能が非x86_64ホストまたはAlpine Linuxでのみ失敗する

拡張機能がDebian 9+、Ubuntu 16.04+、またはRHEL / CentOS 7+のリモートSSHホスト、コンテナ、またはWSLでは動作するものの、サポートされている非x86_64ホスト（例えばARMv7l）またはAlpine Linuxコンテナでは失敗する場合、その拡張機能はこれらのプラットフォームをサポートしないネイティブコードまたはランタイムのみを含んでいる可能性があります。例えば、拡張機能はx86_64用にコンパイルされたネイティブモジュールまたはランタイムのバージョンのみを含んでいるかもしれません。Alpine Linuxの場合、含まれているネイティブコードまたはランタイムは、Alpine Linux（musl）と他のディストリビューション（glibc）でのlibcの実装における根本的な違いのために動作しない可能性があります。

解決策: 拡張機能は、これらの追加ターゲット用のバイナリをコンパイル/含めることで、これらのプラットフォームのサポートにオプトインする必要があります。一部のサードパーティnpmモジュールもこの問題を引き起こす可能性のあるネイティブコードを含んでいる場合があることに注意することが重要です。そのため、場合によってはnpmモジュールの作者と協力して追加のコンパイルターゲットを追加する必要があるかもしれません。詳細については、拡張機能作者ガイドを参照してください。

モジュールが見つからないため拡張機能が失敗する

ElectronまたはVS Codeのベースモジュール（拡張機能APIによって公開されていないもの）に依存し、フォールバックを提供しない拡張機能は、リモートで実行すると失敗する可能性があります。開発者ツールコンソールでoriginal-fsが見つからないなどのエラーが表示されることがあります。

解決策: Electronモジュールへの依存を削除するか、フォールバックを提供してください。詳細については、拡張機能作者ガイドを参照してください。

リモートワークスペースファイルにアクセス/転送できない

ワークスペースファイルを外部アプリケーションで開く拡張機能は、外部アプリケーションがリモートファイルに直接アクセスできないため、エラーが発生する可能性があります。

解決策: ローカルで実行するように設計された「UI」拡張機能を作成する場合、vscode.workspace.fs APIを使用してリモートワークスペースファイルシステムと対話できます。次に、これを「ワークスペース」拡張機能の依存関係とし、必要に応じてコマンドを使用して呼び出すことができます。さまざまな種類の拡張機能と、コマンドを使用してそれらの間で通信する方法の詳細については、拡張機能作者ガイドを参照してください。

拡張機能から接続されているデバイスにアクセスできない

ローカルに接続されたデバイスにアクセスする拡張機能は、リモートで実行されている場合、それらに接続できません。

解決策: 現在ありません。この問題を解決するための最善のアプローチを調査中です。

質問とフィードバック

問題の報告

リモート開発拡張機能のいずれかで問題が発生した場合は、問題を診断できるよう、正しいログを収集することが重要です。

各リモート拡張機能には、そのログを表示するコマンドがあります。

Remote - SSH拡張機能のログは、コマンドパレット（F1）からRemote-SSH: ログを表示で取得できます。Remote - SSHの問題を報告する際は、外部ターミナル（Remote - SSHを使用しない）からマシンにSSH接続できるかどうかも確認してください。

同様に、Dev Containers拡張機能のログは、Dev Containers: コンテナログを表示で取得できます。

上記の2つと同様に、WSL拡張機能のログはWSL: ログを表示で取得できます。また、問題がWSLリポジトリで追跡されているか（そしてWSL拡張機能に起因しないか）も確認してください。

他の拡張機能をリモートで使用する際に問題が発生している場合（例えば、他の拡張機能がリモートコンテキストで正しくロードまたはインストールされない場合など）、Remote Extension Host出力チャネル（出力: 出力ビューにフォーカス）からログを取得し、ドロップダウンからログ（リモート拡張機能ホスト）を選択すると役立ちます。

注: ログ（拡張機能ホスト）のみが表示される場合、これはローカルの拡張機能ホストであり、リモートの拡張機能ホストは起動していません。これは、ログチャネルがログファイル作成後にのみ作成されるため、リモートの拡張機能ホストが起動しない場合、リモートの拡張機能ホストログファイルは作成されず、出力ビューには表示されないためです。これはそれでも、問題に含めるべき有用な情報です。

リモートに関する質問とフィードバックのリソース

他にもさまざまなリモートリソースがあります。

5/28/2026
© . This site is unofficial and not affiliated with Microsoft.