遠端開發秘訣與技巧

本文涵蓋各個 Visual Studio Code 遠端開發 (Remote Development) 擴充功能的疑難排解秘訣與技巧。請參閱 SSH容器 (Containers)WSL 文章,以了解設定與使用各個特定擴充功能的詳細資訊。或者,您也可以嘗試入門教學課程,協助您快速在遠端環境中開始運作。

有關 GitHub Codespaces 的秘訣與問題,請參閱 GitHub Codespaces 文件

SSH 秘訣

SSH 功能強大且靈活,但也增加了一些設定上的複雜度。本節包含一些秘訣與技巧,協助您在不同環境中啟動並執行 Remote - SSH 擴充功能。

自訂 AI 聊天回應

自訂指令能讓您描述常見的指導方針或規則,以獲得符合您特定程式碼慣例與技術堆疊的回應。

您可以使用自訂指令為 Copilot 提供更多關於您所連接的遠端環境類型資訊(例如安裝了哪些語言或工具鏈)。您可以像在本地端一樣使用 copilot-instructions.md 檔案。在使用開發容器時,您也可以採取額外的指令設定步驟

設定 $EDITOR 變數

針對 macOS / Linux 遠端主機,請將此程式碼片段新增至您的 Shell 設定檔(例如 .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)時,會以 VS Code 開啟該檔案,而非預設的終端機編輯器(例如 vimnano)。

設定基於金鑰的驗證

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,請執行以下 Shell 指令,必要時請替換您的私密金鑰路徑

    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: Open Configuration File...,選取一個 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 產生的金鑰

如果您使用 PuTTYGen 為您要連線的主機設定 SSH 公開金鑰驗證,則需要轉換您的私密金鑰,以便其他 SSH 用戶端也能使用它。執行方式如下:

  1. 在本地開啟 PuTTYGen 並載入您想要轉換的私密金鑰。

  2. 從應用程式功能表選取 Conversions > Export OpenSSH key。將轉換後的金鑰儲存到您使用者設定檔資料夾內 .ssh 目錄下的本地位置(例如 C:\Users\youruser\.ssh)。

  3. 驗證此新本地檔案是否由您擁有,且沒有其他使用者有權存取它。

  4. 在 VS Code 中,於命令選擇區 (F1) 執行 Remote-SSH: Open Configuration File...,選取您想要更改的 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 無需驗證即可存取。

預設情況下,伺服器會監聽 localhost 上的隨機 TCP 連接埠,然後轉發到您的本地機器。如果您是連線至 Linux 或 macOS 主機,您可以切換為使用僅限特定使用者的 Unix Socket。此 Socket 將取代連接埠進行轉發。

注意:此設定會停用連線多工處理 (connection multiplexing),因此建議設定公開金鑰驗證

進行設定:

  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 切換為 Socket 模式。

    Listen on socket VS Code setting

  3. 如果您已經連線到該 SSH 主機,請從命令選擇區 (F1) 選取 Remote-SSH: Kill VS Code Server on Host...,以便設定生效。

如果連線時遇到錯誤,您可能需要在 SSH 主機的 sshd 設定中啟用 Socket 轉發。若要執行此操作:

  1. SSH 主機(非本地端)上,使用文字編輯器(如 vi、nano 或 pico)開啟 /etc/ssh/sshd_config
  2. 新增設定 AllowStreamLocalForwarding yes
  3. 重新啟動 SSH 伺服器。(在 Ubuntu 上,執行 sudo systemctl restart sshd。)
  4. 重試。

疑難排解連線掛起或失敗的問題

如果您在嘗試連線時遇到 VS Code 掛起(且可能發生逾時)的問題,您可以採取一些步驟來嘗試解決此問題。

一般疑難排解:移除伺服器

對疑難排解各種 Remote-SSH 問題有幫助的一個指令是 Remote-SSH: Kill VS Code Server on Host。這將會移除伺服器,能修復您可能看到的許多問題與錯誤訊息,例如「無法建立與 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 中新增以下內容,明確告訴 VS Code 您的 SSH 主機是否正在執行 Windows,藉此規避此問題

"remote.SSH.useLocalServer": false

您也可以使用下列屬性強制 VS Code 將特定主機識別為 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_configC:\ProgramData\ssh\sshd_config
  2. 新增設定 AllowTcpForwarding yes
  3. 重新啟動 SSH 伺服器。(在 Ubuntu 上,執行 sudo systemctl restart sshd。在 Windows 上,以管理員 PowerShell 執行 Restart-Service sshd。)
  4. 重試。

在您的 SSH 設定檔中設定 ProxyCommand 參數

如果您位於 Proxy 後方且無法連線到您的 SSH 主機,您可能需要為本地 SSH 設定檔中的主機使用 ProxyCommand 參數。您可以閱讀這篇 SSH ProxyCommand 文章以取得使用範例。

確保遠端機器具有網際網路存取權

遠端機器必須具備網際網路存取權,才能從 Marketplace 下載 VS Code Server 與擴充功能。有關連線需求的詳細資訊,請參閱 常見問題集

在遠端主機上設定 HTTP_PROXY / HTTPS_PROXY

如果您的遠端主機位於 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 會將其安裝指令碼寫入系統暫存目錄並嘗試從該處執行。您可以與系統管理員商討是否能解決此限制。

檢查安裝期間是否啟動了不同的 Shell

有些使用者因為想要使用預設以外的 Shell,而在其 SSH 主機上的 .bash_profile 或其他啟動指令碼中啟動了不同的 Shell。這可能會破壞 VS Code 的遠端伺服器安裝指令碼,因此不建議這樣做。請改用 chsh 來變更遠端機器上的預設 Shell。

連線至每次連線都會動態指派機器的系統

有些系統會在每次建立 SSH 連線時,將 SSH 連線動態路由至叢集中的某個節點。這對 VS Code 來說是個問題,因為它需要建立兩個連線來開啟遠端視窗:第一個是安裝或啟動 VS Code Server(或尋找已在執行的執行個體),第二個是建立 VS Code 用來與伺服器對話的 SSH 連接埠通道。如果在建立第二個連線時,VS Code 被路由到另一台機器,它將無法與 VS Code Server 通訊。

解決此問題的一個方法是在 OpenSSH 中使用 ControlMaster 選項(僅限 macOS/Linux 用戶端),如啟用替代 SSH 驗證方法中所述,這樣 VS Code 的兩個連線將會透過對同一節點的單一 SSH 連線進行多工處理。

聯絡您的系統管理員以取得設定協助

SSH 是一個非常靈活的協定,支援許多種設定。如果您在登入終端機或 Remote-SSH 輸出視窗中看到其他錯誤,可能是因為缺少了某些設定。

請聯絡您的系統管理員,取得有關您的 SSH 主機與用戶端所需設定的資訊。連線至 SSH 主機的特定命令列參數可以新增至 SSH 設定檔

若要存取您的設定檔,請在命令選擇區 (F1) 中執行 Remote-SSH: Open Configuration File...。接著您就可以與管理員合作新增必要的設定。

啟用替代 SSH 驗證方法

如果您連線至 SSH 遠端主機且符合以下情況:

  • 使用雙重驗證連線
  • 使用密碼驗證
  • SSH Agent 未執行或無法存取時,使用帶有複雜密碼的 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 來建立 sockets 資料夾。

設定 SSH Agent

如果您使用帶有複雜密碼的金鑰連線至 SSH 主機,則應確保 SSH Agent 正在本地執行。VS Code 會自動將您的金鑰新增至 Agent,這樣您就不必每次開啟遠端 VS Code 視窗時都輸入複雜密碼。

若要驗證 Agent 是否正在執行且可從 VS Code 環境存取,請在本地 VS Code 視窗的終端機中執行 ssh-add -l。您應該會看到 Agent 中的金鑰清單(或表示沒有金鑰的訊息)。如果 Agent 未執行,請按照這些說明啟動它。啟動 Agent 後,請務必重新啟動 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

現在 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

Agent 在 macOS 上應預設執行。

讓遠端機器可以使用本地 SSH Agent

您本地機器上的 SSH Agent 允許 Remote - SSH 擴充功能連線至您選擇的遠端系統,而無需重複提示輸入複雜密碼;但是,執行在遠端上的工具(如 Git)無法存取您本地解鎖的私密金鑰。

您可以透過在遠端開啟整合終端機並執行 ssh-add -l 來確認這一點。該指令應列出已解鎖的金鑰,但現在卻回報無法連線到驗證 Agent 的錯誤。設定 ForwardAgent yes 可讓遠端環境使用本地 SSH Agent,從而解決此問題。

您可以編輯您的 .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 Client

在這種情況下,請確保 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 Wiki,以了解如何為 Windows OpenSSH 伺服器設定適當的檔案權限。

安裝受支援的 SSH 用戶端

作業系統 指示
Windows 10 1803+ / Server 2016/2019 1803+ 安裝 Windows OpenSSH Client
較舊的 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 伺服器

作業系統 指示 詳細資訊
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 中,前往服務管理員 (Services Manager),在清單中選取 "sshd" 並點擊啟用。接著前往防火牆,選取永久設定,並在服務下方勾選 sshd 詳細資訊請參閱 SuSE SSH 文件。
Windows 10 1803+ / Server 2016/2019 1803+ 安裝 Windows OpenSSH Server
macOS 10.14+ (Mojave) 啟用 遠端登入 (Remote Login)

解決 SSH 主機上執行 Git push 或同步時的掛起問題

如果您使用 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 下可用。完成後,您可以使用作業系統的 Finder / 檔案總管或透過命令列將其卸載

umount "$HOME/sshfs/$USER_AT_HOST"

Windows

遵循以下步驟

  1. 在 Linux 上,請將 .gitattributes 檔案新增至您的專案,以強制 Linux 與 Windows 之間的一致行尾,避免因兩作業系統之間的 CRLF/LF 差異而導致意料之外的問題。詳細資訊請參閱 解決 Git 行尾問題

  2. 接下來,使用 Chocolatey 安裝 SSHFS-Winchoco 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 維護原始程式碼的本地副本

存取遠端檔案的另一種選擇是 使用 rsync 將遠端主機上某個資料夾的全部內容複製到您的本地機器。rsync 指令會在每次執行時判斷哪些檔案需要更新,這比使用 scpsftp 等工具更有效率且方便。如果確實需要使用效能密集的本地工具,請優先考慮此方案。

rsync 指令在 macOS 上是開箱即用的,也可以透過 Linux 套件管理員安裝(例如 Debian/Ubuntu 上的 sudo apt-get install rsync)。對於 Windows,您需要使用 WSLCygwin 才能存取該指令。

若要使用此指令,請導覽至您想要儲存同步內容的資料夾,並執行以下指令,將 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: Uninstall VS Code Server from Host...。該指令會執行兩件事:刪除任何正在執行的 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 下,因此您也可以檢查該位置。

透過 SSH 連線至遠端 WSL 2 主機

您可能想要使用 SSH 連線至執行在遠端機器上的 WSL 發行版。請查看 這份指南,以了解如何從外部機器透過 SSH 連線至 Windows 10 上的 Bash 與 WSL 2。

提交問題

如果您在使用 Remote-SSH 擴充功能時遇到問題並認為需要提交 Issue,請先確保您已閱讀本網站上的文件,然後參閱 疑難排解 Wiki 文件,以取得獲取記錄檔的資訊,並嘗試更多有助於縮小問題來源範圍的步驟。

Dev Containers 秘訣

如果您想閱讀關於使用 Dev Containers 的秘訣,可以前往 Dev Containers 的 秘訣與技巧

WSL 秘訣

首次啟動:VS Code Server 先決條件

某些 WSL Linux 發行版缺乏 VS Code Server 啟動所需的程式庫。您可以使用 Linux 發行版的套件管理員新增額外的程式庫。

Debian 與 Ubuntu

開啟 Debian 或 Ubuntu WSL Shell 以新增 wgetca-certificates

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

Alpine

以 root 身分開啟 Alpine WSL Shell (wsl -d Alpine -u root) 以新增 libstdc++

apk update && apk add libstdc++

在 Windows 10 2018 年 4 月更新 (組建 1803) 與更舊版本上,需要 /bin/bash

apk update && apk add bash

選擇 WSL 擴充功能使用的發行版

WSL: New Window 將會開啟已註冊為預設的 WSL 發行版。

若要開啟非預設發行版,請從要使用的發行版 WSL Shell 中執行 code .,或使用 WSL: New Window using Distro

在 Windows 10 2019 年 5 月更新(版本 1903)之前的 WSL 版本中,WSL 指令只能使用預設發行版。因此,WSL 擴充功能可能會詢問您是否同意更改預設發行版。

您隨時可以使用 wslconfig.exe 來變更您的預設值。

例如

wslconfig /setdefault Ubuntu

您可以透過執行以下指令查看已安裝的發行版

wslconfig /l

為伺服器啟動設定環境

當 WSL 擴充功能在 WSL 中啟動 VS Code Server 時,它不會執行任何 Shell 設定指令碼。這是為了避免自訂設定指令碼導致啟動失敗。

如果您需要設定啟動環境,可以使用此處描述的環境設定指令碼。

為遠端擴充主機設定環境

遠端擴充主機與終端機的環境是基於預設 Shell 的設定指令碼。為了評估遠端擴充主機程序的環境變數,伺服器會以互動式登入 Shell 建立一個預設 Shell 的執行個體。它會從中探測環境變數,並將其用作遠端擴充主機程序的初始環境。因此,環境變數的值取決於設定為預設的 Shell 以及該 Shell 設定指令碼的內容。

有關各個 Shell 設定指令碼的總覽,請參閱 Unix Shell 初始化。大多數 WSL 發行版將 /bin/bash 設定為預設 Shell。/bin/bash 會先搜尋 /etc/profile 下的啟動檔案,再搜尋 ~/.bash_profile~/.bash_login~/.profile 下的任何啟動檔案。

若要變更 WSL 發行版的預設 Shell,請按照 這篇部落格文章 的說明進行操作。

修正 'code' 指令無法運作的問題

如果在 Windows 上從 WSL 終端機輸入 code 無效,是因為系統找不到 code,您可能在 WSL 的 PATH 中遺失了某些關鍵位置。

開啟 WSL 終端機並輸入 echo $PATH 來檢查。您應該會看到列出的 VS Code 安裝路徑。預設情況下,這會是

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

但是,如果您使用了系統安裝程式,安裝路徑為

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

...或...

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

WSL 的一個特性是路徑繼承自 Windows 中的 PATH 變數。若要變更 Windows PATH 變數,請使用 Windows 開始選單中的編輯您的帳戶環境變數指令。

如果您已停用路徑共用功能,請編輯您的 .bashrc,新增以下內容,並啟動一個新的終端機

WINDOWS_USERNAME="Your Windows Alias"

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

注意:請務必對目錄名稱中的空格字元加上引號或進行跳脫處理。

找出 'code' 指令的問題

如果在 Windows 命令提示字元輸入 code 無法啟動 VS Code,您可以執行 VSCODE_WSL_DEBUG_INFO=true code . 來協助我們診斷問題。

請提交 Issue 並附上完整輸出。

找出啟動伺服器或連線至伺服器的問題

當 WSL 視窗無法連線到遠端伺服器時,您可以在 WSL 記錄檔中取得更多資訊。提交 Issue 時,務必傳送 WSL 記錄檔的完整內容非常重要。

執行 WSL: Open Log 指令以開啟 WSL 記錄檔。記錄檔將顯示在終端機檢視中的 WSL 索引標籤下方。

WSL Log

若要獲得更詳盡的記錄,請在使用者設定中啟用 remote.WSL.debug 設定。

伺服器啟動時出現區段錯誤 (Segmentation fault)

您可以透過傳送核心傾印檔 (Core dump file) 來協助我們調查此問題。若要取得核心傾印檔,請遵循下列步驟

在 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 Open in VS Code Open in VS Code Insiders 來控制要觀察的資料夾。

WSL 2 沒有該檔案觀察器問題,也不受新設定的影響。

解決 WSL 中的 Git 行尾問題(導致大量已修改檔案)

由於 Windows 與 Linux 使用不同的預設行尾,Git 可能會回報大量除了行尾外並無差異的已修改檔案。為防止這種情況發生,您可以透過 .gitattributes 檔案或全域設定在 Windows 端停用行尾轉換。

通常在您的儲存庫中新增或修改 .gitattributes 檔案是解決此問題最可靠的方法。將此檔案提交到原始程式碼控制中將有助於他人,並允許您根據儲存庫適當調整行為。例如,將以下內容加入儲存庫根目錄的 .gitattributes 檔案,將會強制所有檔案使用 LF,但需要 CRLF 的 Windows 批次檔除外

* 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 中設定了 認證協助程式 (credential helper),您可以將其與 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 或同步時的掛起問題

如果您使用 SSH 複製 Git 儲存庫,且您的 SSH 金鑰具有複雜密碼,VS Code 的 pull 與 sync 功能在遠端執行時可能會掛起。

若要規避此問題,請使用沒有複雜密碼的 SSH 金鑰、透過 HTTPS 複製,或從命令列執行 git push

GitHub Codespaces 秘訣

有關 GitHub Codespaces 的秘訣與問題,請參閱 GitHub Codespaces 文件。您也可以查看可能影響 Codespaces 的 已知網頁限制與調整方案

擴充功能秘訣

雖然許多擴充功能在未經修改的情況下即可運作,但仍有一些問題可能會阻止特定功能如預期般運作。在某些情況下,您可以使用其他指令來規避問題,而在其他情況下,則可能需要修改擴充功能。本節提供常見問題與解決技巧的快速參考。您也可以參閱關於 支援遠端開發 的主要擴充功能文章,以取得修改擴充功能以支援遠端擴充主機的深入指南。

解決缺少相依性的錯誤

有些擴充功能依賴於特定 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... 指令。您可能也希望將 "extensions.autoUpdate": false 加入 settings.json,以防止自動更新到最新的 Marketplace 版本。有關在遠端環境中開發與測試擴充功能的詳細資訊,請參閱 支援遠端開發

瀏覽器無法在本地開啟

有些擴充功能使用外部 node modules 或自訂程式碼來啟動瀏覽器視窗。遺憾的是,這可能會導致擴充功能在遠端啟動瀏覽器,而非在本地端啟動。

解決方法:擴充功能可以使用 vscode.env.openExternal API 來解決此問題。詳細資訊請參閱 擴充功能作者指南

剪貼簿無法運作

有些擴充功能使用如 clipboardy 等 node modules 來與剪貼簿整合。遺憾的是,這可能會導致擴充功能錯誤地與遠端的剪貼簿進行整合。

解決方法:擴充功能可以切換至 VS Code 剪貼簿 API 以解決此問題。詳細資訊請參閱 擴充功能作者指南

無法從瀏覽器或應用程式存取本地 Web 伺服器

在容器、SSH 主機或透過 GitHub Codespaces 工作時,瀏覽器連線的連接埠可能會被封鎖。

解決方法:擴充功能可以使用 vscode.env.openExternalvscode.env.asExternalUri API(會自動轉發 localhost 連接埠)來解決此問題。詳細資訊請參閱 擴充功能作者指南。作為替代方案,請使用 Forward a Port 指令手動執行此操作。

Webview 內容未顯示

如果擴充功能的 Webview 內容使用 iframe 來連線至本地 Web 伺服器,則該 Webview 連線的連接埠可能會被封鎖。此外,如果擴充功能將 vscode-resource:// URI 硬編碼而非使用 asWebviewUri,內容可能不會顯示在 Codespaces 瀏覽器編輯器中。

解決方法:擴充功能可以使用 webview.asWebviewUri 來解決與 vscode-resource:// URI 相關的問題。

如果連接埠被封鎖,最好的方法是改用 Webview 訊息傳遞 API。作為替代方案,vscode.env.asExternalUri 可用於允許 Webview 連線至 VS Code 產生的 localhost Web 伺服器。然而,此方法目前(僅)針對 Codespaces 基於瀏覽器的編輯器被 MicrosoftDocs/vscodespaces#11 封鎖。有關該替代方案的詳細資訊,請參閱 擴充功能作者指南

已封鎖的 localhost 連接埠

如果您嘗試從外部應用程式連線至 localhost 連接埠,該連接埠可能會被封鎖。

解決方法:VS Code 1.40 引入了一個新的 vscode.env.asExternalUri API,供擴充功能以程式設計方式轉發任意連接埠。詳細資訊請參閱 擴充功能作者指南。作為替代方案,您可以使用 Forward a Port 指令手動執行此操作。

儲存擴充功能資料時發生錯誤

擴充功能可能會嘗試透過在 Linux 上搜尋 ~/.config/Code 資料夾來保存全域資料。該資料夾可能不存在,這會導致擴充功能拋出如 ENOENT: no such file or directory, open '/root/.config/Code/User/filename-goes-here 的錯誤。

解決方法:擴充功能可以使用 context.globalStorageUricontext.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 穩定版執行 rm -rf ~/.vscode-server/extensions,和/或針對 VS Code Insiders 執行 rm -rf ~/.vscode-server-insiders/extensions,以移除所有擴充功能。

隨附或取得預先建置原生模組的擴充功能失敗

與 VS Code 擴充功能捆綁(或動態取得)的原生模組必須 使用 Electron 的 electron-rebuild 重新編譯。然而,VS Code Server 執行的是標準(非 Electron)版本的 Node.js,這可能會導致二進位檔在遠端使用時失敗。

解決方法:需要修改擴充功能才能解決此問題。它們將需要包含(或動態取得)針對 VS Code 所附帶 Node.js 的「模組」版本所對應的兩組二進位檔(Electron 與標準 Node.js),然後在啟動函式中檢查 context.executionContext === vscode.ExtensionExecutionContext.Remote 以設定正確的二進位檔。詳細資訊請參閱 擴充功能作者指南

擴充功能僅在非 x86_64 主機或 Alpine Linux 上失敗

如果擴充功能在 Debian 9+、Ubuntu 16.04+ 或 RHEL / CentOS 7+ 的遠端 SSH 主機、容器或 WSL 上運作正常,但在受支援的非 x86_64 主機(例如 ARMv7l)或 Alpine Linux 容器上失敗,該擴充功能可能僅包含不支援這些平台原生程式碼或執行階段。例如,擴充功能可能僅包含 x86_64 編譯版本的原生模組或執行階段。對於 Alpine Linux,所包含的原生程式碼或執行階段可能會因為 Alpine Linux (musl) 與其他發行版 (glibc) 在 libc 實作方式上的 基本差異 而無法運作。

解決方法:擴充功能將需要透過編譯/包含這些額外目標的二進位檔來選擇性支援這些平台。值得注意的是,某些第三方 npm 模組也可能包含會導致此問題的原生程式碼。因此,在某些情況下,您可能需要與 npm 模組作者合作以增加額外的編譯目標。詳細資訊請參閱 擴充功能作者指南

擴充功能因缺少模組而失敗

依賴 Electron 或 VS Code 基礎模組(未經擴充功能 API 公開)且未提供備援機制的擴充功能,在遠端執行時可能會失敗。您可能會在開發人員工具主控台中看到如找不到 original-fs 的錯誤。

解決方法:移除對 Electron 模組的相依性或提供備援機制。詳細資訊請參閱 擴充功能作者指南

無法存取/傳輸遠端工作區檔案至本地機器

在外部應用程式中開啟工作區檔案的擴充功能可能會遇到錯誤,因為外部應用程式無法直接存取遠端檔案。

解決方法:如果您建立了一個設計為在本地端執行的「UI」擴充功能,您可以使用 vscode.workspace.fs API 與遠端工作區檔案系統進行互動。接著,您可以將此擴充功能設為您的「工作區」擴充功能的相依項目,並根據需要使用指令來呼叫它。有關不同類型的擴充功能以及如何使用指令在它們之間進行通訊的詳細資訊,請參閱 擴充功能作者指南

擴充功能無法存取連接的裝置

存取本地連接裝置的擴充功能在遠端執行時將無法連線至該裝置。

解決方法:目前沒有。我們正在研究解決此問題的最佳方法。

問題與回饋

回報問題

如果您在使用遠端開發擴充功能時遇到問題,務必收集正確的記錄檔,以便我們能夠協助 診斷您的問題

每個遠端擴充功能都有一個檢視其記錄檔的指令。

您可以從命令選擇區 (F1) 使用 Remote-SSH: Show Log 取得 Remote - SSH 擴充功能記錄檔。回報 Remote - SSH 問題時,請同時驗證您是否能從外部終端機(不使用 Remote - SSH)SSH 連線至您的機器。

同樣地,您可以使用 Dev Containers: Show Container Log 取得 Dev Containers 擴充功能記錄檔。

像上面兩個一樣,您可以使用 WSL: Show Log 取得 WSL 擴充功能記錄檔。同時檢查您的問題是否正在 WSL repo 中進行追蹤(且不是因 WSL 擴充功能所引起)。

如果您在遠端使用其他擴充功能時遇到問題(例如,其他擴充功能在遠端環境中未正確載入或安裝),從 Remote Extension Host 輸出頻道 (Output: Focus on Output View) 擷取記錄檔會很有幫助,並從下拉式選單中選取 Log (Remote Extension Host)

注意:如果您只看到 Log (Extension Host),這是本地擴充主機的記錄,代表遠端擴充主機並未啟動。這是因為記錄頻道是在記錄檔建立後才會建立,因此如果遠端擴充主機未啟動,遠端擴充主機記錄檔就不會建立,也不會顯示在輸出檢視中。不過這對於您提交 Issue 來說,依然是有用的資訊。

遠端問題與意見回饋資源

我們還有許多其他的遠端資源

© . This site is unofficial and not affiliated with Microsoft.