に参加して、VS Code の AI 支援開発について学びましょう。

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

この記事では、Visual Studio Codeのリモート開発拡張機能ごとのトラブルシューティングのヒントとテクニックについて説明します。各拡張機能のセットアップと使用方法の詳細については、SSH、コンテナー、WSLの記事を参照してください。または、リモート環境で迅速に作業を開始するための入門チュートリアルを試してみてください。

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

SSHのヒント

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

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

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

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

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

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パスにも/を使用できます。\を使用する場合は、二重スラッシュを使用する必要があります。例: C:\\path\\to\\my\\id_ed25519。

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

接続先のホストにSSH公開鍵認証を設定するためにPuTTYGenを使用した場合は、他の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

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

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

デフォルトでは、サーバーはランダムな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 Server Listen On Socketを有効にすることで、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転送を有効にする

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

open failed: administratively prohibited: open failed

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

  1. SSHホスト上（ローカルではない）で、テキストエディター（Vim、nano、Pico、またはメモ帳など）で/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サーバーと拡張機能をマーケットプレイスからダウンロードできるように、リモートマシンがインターネットにアクセスできる必要があります。接続要件の詳細については、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をインストールまたは起動するため（またはすでに実行中のインスタンスを見つけるため）、2つ目はVS Codeがサーバーと通信するために使用するSSHポートトンネルを作成するためです。VS Codeが2番目の接続を作成するときに別のマシンにルーティングされた場合、VS Code Serverと通信できなくなります。

この問題の回避策の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エージェントは、リモート - SSH拡張機能がパスフレーズの入力を繰り返し求められることなく、選択したリモートシステムに接続できるようにしますが、リモートで実行されるGitのようなツールは、ローカルでロック解除された秘密鍵にアクセスできません。

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

これは、.ssh/configファイルを編集（またはRemote.SSH.configFileが設定されているものを使用 - Remote-SSH: Open SSH Configuration File...コマンドを使用して確認）し、次の行を追加することで実行できます。

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間で一貫した改行コードを強制するために、プロジェクトに.gitattributesファイルを追加して、両方のオペレーティングシステム間のCRLF/LFの違いによる予期しない問題を回避します。詳細については、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サーバーのクリーンアップ

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

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

# 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サーバーの前提条件

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

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

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エラーが発生する

これはWSLファイルシステムの実装における既知の問題（Microsoft/WSL#3395、Microsoft/WSL#1956）であり、VS Codeがアクティブにしているファイルウォッチャーによって引き起こされます。この問題は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 <package>を実行して必要なライブラリをインストールします。追加のインストール詳細については、拡張機能のドキュメントまたはエラーメッセージで言及されているランタイムを確認してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ブロックされた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サーバーが互換性のためにハングまたはクラッシュする事例が見られます。拡張機能がすぐにアクティブ化されると、接続できなくなり、拡張機能をアンインストールできなくなる可能性があります。

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

  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サーバーは標準の（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モジュール作成者と協力して追加のコンパイルターゲットを追加する必要があるかもしれません。詳細については、拡張機能開発者向けガイドを参照してください。

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

拡張機能APIによって公開されていないElectronまたはVS Code基本モジュールに依存し、フォールバックを提供しない拡張機能は、リモートで実行すると失敗する可能性があります。Developer Toolsコンソールに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出力チャネル（出力: 出力ビューにフォーカス）からログを取得し、ドロップダウンからLog (Remote Extension Host)を選択すると役立ちます。

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

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

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

10/09/2025
© . This site is unofficial and not affiliated with Microsoft.