🚀 VS Codeでを入手しましょう！

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

この記事では、Visual Studio Code Remote Development 拡張機能のそれぞれのトラブルシューティングのヒントとテクニックについて説明します。各特定の拡張機能の設定と操作の詳細については、SSH、コンテナ、および WSL の記事を参照してください。または、リモート環境で迅速に実行できるようにするための入門 チュートリアル を試してみてください。

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

SSH のヒント

SSH は強力で柔軟性がありますが、セットアップの複雑さも増します。このセクションでは、Remote - SSH 拡張機能をさまざまな環境で起動して実行するためのヒントとテクニックを紹介します。

$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
}

これで、$EDITOR 変数を使用するターミナルコマンド (git commit など) を実行すると、デフォルトのターミナルベースのエディター (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 サーバーを使用し、ユーザーは 管理者グループに属しています

      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 サーバーを使用し、ユーザーは 管理者グループに属しています

      $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. アプリケーションメニューから [Conversions > Export OpenSSH key] を選択します。変換されたキーを、ユーザープロファイルフォルダーの .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. Remote.SSH: リモートサーバーがソケットでリッスン をローカル VS Code ユーザー設定 で有効にして、Remote - SSH をソケットモードに切り替えます。

    Listen on socket VS Code setting

  3. SSH ホストに既に接続している場合は、コマンドパレット (F1) から [Remote-SSH: ホスト上の VS Code サーバーを強制終了...] を選択して、設定を有効にします。

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

  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 サーバーでは発生しません。

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

"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 config を更新します。

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

この回避策の 1 つは、代替 SSH 認証方法の有効化 で説明されているように、OpenSSH (macOS/Linux クライアントのみ) の ControlMaster オプションを使用して、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 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 を見つけようとします。remote.SSH.path プロパティを settings.json に追加することで、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 Server 2016/2019 1803+
macOS 10.14+ (Mojave) リモートログイン を有効にします。

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

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

パスフレーズなしの 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 間で一貫した改行コードを強制するために、プロジェクトに .gitattributes ファイルを追加して、2 つのオペレーティングシステム間の CRLF/LF の違いによる予期しない問題を回避してください。詳細については、Git の改行コードの問題の解決 を参照してください。

  2. 次に、SSHFS-Win を Chocolatey を使用してインストールします: 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 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 ドキュメント を参照して、ログファイルの取得方法と、問題の原因を絞り込むのに役立つ可能性のある追加の手順を確認してください。

開発コンテナのヒント

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 シェルを 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: ディストリビューションを使用した新しいウィンドウ を使用します。

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

パスは Windows の PATH 変数から継承されるのが WSL の機能です。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 します。
  • VS Code で wslServer.sh スクリプトを開きます (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 で監視するフォルダーを制御することができます。

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 push または sync を実行するときのハングアップの解決

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

パスフレーズなしの 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) から Preferences: Open Remote Settings コマンドを実行するか、設定エディターで Remote タブを選択して、エンドポイント固有の設定を行うことができます。これらの設定は、接続するたびに設定されているローカル設定をオーバーライドします。

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

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

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

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

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

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

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

一部の拡張機能は、clipboardy などのノードモジュールを使用してクリップボードと統合します。残念ながら、これにより、拡張機能がリモート側のクリップボードと誤って統合する可能性があります。

解決策: 拡張機能は 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 サーバーに接続できるようになります。ただし、これは現在、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 <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 の「modules」バージョン用に、両方のバイナリセット (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 モジュールの作成者と協力して、追加のコンパイルターゲットを追加する必要がある場合があります。詳細については、拡張機能作成者向けガイド を参照してください。

モジュールが不足しているために拡張機能が失敗する

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

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

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

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

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

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

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

解決策: 現在はありません。この問題を解決するための最良のアプローチを調査しています。

質問とフィードバック

問題の報告

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

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

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

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

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

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

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

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

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

04/03/2025