リモート開発のヒントとテクニック

この記事では、Visual Studio Code のリモート開発拡張機能それぞれのトラブルシューティングのヒントとテクニックを説明します。SSH、コンテナー、および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 設定ファイルを選択して、次のように設定ファイルにホストエントリを追加 (または変更) して、ファイルを指すようにします。

   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」をインストールし、維持します。サーバーはランダムに生成されたキーで起動され、サーバーへの新しい接続はすべてキーを提供する必要があります。キーはリモートのディスクに保存され、現在のユーザーのみが読み取ることができます。認証なしでアクセスできる HTTP パスは /version の 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 をソケットモードに切り替えます。

   

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 を終了です。これによりサーバーが削除され、「server_name への接続を確立できませんでした: VS Code Server の起動に失敗しました」など、表示されるさまざまな問題やエラーメッセージを修正できます。

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 として強制的に識別させることもできます。

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

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

設定のヘルプについては、システム管理者に連絡してください。

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

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

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

代替SSH認証方法の有効化

SSH リモートホストに接続しており、次のいずれかに該当する場合:

• 二要素認証での接続
• パスワード認証の使用
• 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 Agentがローカルで実行されていることを確認する必要があります。VS Code は自動的にキーをエージェントに追加するため、リモート VS Code ウィンドウを開くたびにパスフレーズを入力する必要がありません。

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

Windows

Windows で SSH Agent を自動的に有効にするには、ローカル管理者 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 Agent をバックグラウンドで起動するには、次を実行します。

eval "$(ssh-agent -s)"

ログイン時にSSH Agentを自動的に起動するには、~/.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

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

Windows

具体的な期待されるアクセス許可は、使用している SSH の実装によって異なる場合があります。箱から出してすぐに使えるWindows 10 OpenSSH クライアントの使用をお勧めします。

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

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

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

macOS / Linux

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

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

Windows

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

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

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

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

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

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

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

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

SSHFS は、SFTP を基盤とする安全なリモートファイルシステムアクセスプロトコルです。マシンへの SSH アクセスのみが必要であるため、CIFS / Samba 共有のようなものよりも優れています。

注: パフォーマンス上の理由から、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 では、CRLF/LF の違いによる予期しない問題を防ぐため、プロジェクトに .gitattributes ファイルを追加して、Linux と Windows 間で行末の一貫性を強制します。詳細については、Git 行末の問題の解決を参照してください。

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

3. SSHFS for Windows をインストールしたら、ファイルエクスプローラーのネットワークドライブの割り当て...オプションをパス\\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 Server をアンインストール...があります。このコマンドは 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 接続

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

問題の報告

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

開発コンテナのヒント

開発コンテナーの使用に関するヒントを読みたい場合は、開発コンテナーのヒントとテクニックに進むことができます。

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 シェルを root で開き (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: Distro を使用して新しいウィンドウを使用します。

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 ディストロのデフォルトシェルを変更するには、このブログ記事の指示に従ってください。

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

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 タブに表示されます。

さらに詳細なログ記録を取得するには、ユーザー設定で 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: 許可されていないエラーが発生する

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

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

大規模なワークスペースの場合、ポーリング間隔 remote.WSL.fileWatcher.pollingInterval を増やし、files.watcherExclude で監視するフォルダーを制御できます。

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 を実行して必要なライブラリをインストールします。追加のインストール詳細については、拡張機能のドキュメントまたはエラーメッセージで言及されているランタイムを確認してください。

ローカル絶対パス設定がリモートで適用されると失敗する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Webview の内容が表示されない

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

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

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

ブロックされた localhost ポート

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

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

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

拡張機能は、Linux 上の ~/.config/Code フォルダーを探してグローバルデータを永続化しようとする場合があります。このフォルダーが存在しない場合、拡張機能は ENOENT: no such file or directory, open '/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 /bin/sh を実行します。実行中の場合は、docker exec -it /bin/sh を実行します。

3. 接続したら、VS Code 安定版の場合は 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 バージョンを実行するため、リモートで使用するとバイナリが失敗する可能性があります。

解決策: 拡張機能は、この問題を解決するために変更する必要があります。アクティベーション関数で context.executionContext === vscode.ExtensionExecutionContext.Remote をチェックして正しいバイナリを設定するために、VS Code が出荷する Node.js の「モジュール」バージョン用の両方のバイナリ (Electron と標準 Node.js) を含める (または動的に取得する) 必要があります。詳細については、拡張機能作成者ガイドを参照してください。

拡張機能が 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 を使用してリモートワークスペースファイルシステムと対話できます。その後、これを「ワークスペース」拡張機能の依存関係にし、必要に応じてコマンドを使用して呼び出すことができます。さまざまな種類の拡張機能と、それらの間でコマンドを使用して通信する方法の詳細については、拡張機能作成者ガイドを参照してください。

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

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

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

質問とフィードバック

問題の報告

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

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

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

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

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

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

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

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

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

• リモート開発の FAQ を参照してください。
• Stack Overflowで検索します。
• 機能リクエストを追加するか、問題を報告します。