Remote server status check can fail if you have a .curlrc file

[tru]

• VSCode Version: 1.50.1
• Local OS Version: Windows 10
• Remote OS Version: Clear Linux
• Remote Extension/Connection Type: SSH

Steps to Reproduce:

1. Create a .curlrc on remote OS and use --remote-name-all in it since this allows curl to work as wget (i.e writing to file when downloading)
2. Connect from other host. Status check will fail since it won't echo the output to stdout
3. Be very confused

Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes

Curl should be called with -q which ignores the .curlrc to avoid this.

[roblourens]

For the status check, we need to add --no-remote-name (not for the download)

[roblourens]

I have no idea where I got --no-remote-name from... it doesn't seem to exist as an option and is causing problems for me.

• Set "remote.SSH.remoteServerListenOnSocket": true so it uses curl instead of wget
• Connect to a remote
• Connect a second time (so it's connecting to a server that is already running)

Get an error message that the flag can't be used.

I'm a little nervous about using -q because there might be some other necessary flag in the config file, like for a proxy, but since we are connecting to a local address that probably won't matter, so using -q like originally suggested might be a better fix. I can't find another way to override --remote-name and force curl to use stdout

[tanhakabir]

When I try with -q and useLocalServer: true I see:

[13:37:53.993] Server status check failed - waiting and retrying

[eleanorjboyd]

Hello! My name is Eleanor the new maintainer for Remote-SSH. After reviewing this issue it seems the fix decided is to add the -q tag to the .curlrc command. I will review this suggestion to make sure -q as described by the curl man pages does what we expect and that this will not be a breaking change to different setups for users. Thanks

[joshspicer]

Tomorrow's pre-release build of the extension will start to ignore curlrc and wgetrc files by default, ensuring that this extension can run in isolation of a user's configuration.

Additionally, I've added the remote.SSH.useCurlAndWgetConfigurationFiles setting which one can enable to continue honoring these configuration files. I don't believe there will be many reasons to do so - please let me know if you find a need to enable this setting!

[joshspicer]

Validation steps

Setup/Cleanup (repeat for each section below)

1. Use insiders
2. Set up a remote machine that is either linux or Mac-based (SSH'ing to your Mac over localhost is fine too)
3. Delete ~/.vscode-server-insiders/ on the remote to ensure the server/CLI aren't cached
4. Run > Remote-SSH: Kill VS Code Server on Host against your remote machine to ensure a clean slate
5. Add some setting to both curlrc and wgetrc that will clearly fail (I set non-existant proxies, see below)
   • 

(A) Test with defaults

1. Follow Setup/Cleanup
2. Ensure that remote.SSH.useCurlAndWgetConfigurationFiles is set to false (Default value)
3. Attempt to connect to the remote machine with the extension
4. Confirm in the Remote-SSH output logs that wget was used successfully:

...
[13:53:41.084] > Downloading with wget
[13:53:43.750] > Download complete
...

(B) Test with curl

wget is preferred if available on your local machine, this sequence of steps "removes" wget so that the curl codepath is exercised.

1. Follow Setup/Cleanup
2. Ensure that remote.SSH.useCurlAndWgetConfigurationFiles is still set to false (Default value)
3. Change the name of the wget binary on your remote's $PATH so that the curl codepath is used:
   eg:

[~]$ which wget
/opt/homebrew/bin/wget
[~]$ mv /opt/homebrew/bin/wget /opt/homebrew/bin/wget-DISABLED

1. Confirm in the Remote-SSH output logs that wget was used successfully:

...
[13:58:31.011] > Downloading with curl
[13:58:31.018] stderr>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[13:58:31.018] stderr>                                  Dload  Upload   Total   Spent    Left  Speed
[13:58:31.018] stderr> 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
[13:58:31.187] stderr> 
100   162  100   162    0     0    965      0 --:--:-- --:--:-- --:--:--   970
[13:58:31.757] stderr> 
 87 5835k   87 5088k    0     0  6895k      0 --:--:-- --:--:-- --:--:-- 6895k
[13:58:31.852] stderr> 
100 5835k  100 5835k    0     
[13:58:31.853] stderr> 0  7006k      0 --:--:-- --:--:-- --:--:-- 7871k
[13:58:31.858] > Download complete
...

(C) Test with fallback setting enabled

1. Follow Setup/Cleanup
2. Ensure that remote.SSH.useCurlAndWgetConfigurationFiles is set to TRUE
3. Attempt to connect to the remote machine with the extension
4. Note that wget will fail. (This is expected since it's honoring the remote's wgetrc, but will fallback to scp'ing from the local host.)

[14:02:32.253] Copying file to remote with scp -o ConnectTimeout=15 'vscode-cli-22e3447b4b410dcf8426bf70743c5dd4030d6122.tar.gz' 'vscode-cli-22e3447b4b410dcf8426bf70743c5dd4030d6122.tar.gz.done' localhost:'/Users/joshspicer/.vscode-server-insiders'
[14:02:32.254] Using cwd: file:///var/folders/rn/8hrxbc556pq_020kvg5hm8qh0000gn/T/vscode_server_1721854952225
[14:02:32.577] "Copy server to host" terminal received data: "
(joshspicer@localhost) Password:"
[14:02:32.577] Showing password prompt
[14:02:34.854] >  
[14:02:36.549] Got password response
[14:02:36.549] "Copy server to host" wrote data to terminal: "******************"
[14:02:36.565] "Copy server to host" terminal received data: ""
[14:02:36.800] "Copy server to host" terminal received data: "
vscode-cli-22e3447b4b410dcf8426bf70743c5dd403   0%    0     0.0KB/s   --:-- ETA"
[14:02:36.828] "Copy server to host" terminal received data: "
vscode-cli-22e3447b4b410dcf8426bf70743c5dd403 100% 5836KB 197.2MB/s   00:00    

vscode-cli-22e3447b4b410dcf8426bf70743c5dd403   0%    0     0.0KB/s   --:-- ETA
vscode-cli-22e3447b4b410dcf8426bf70743c5dd403 100%    9    52.6KB/s   00:00    "
[14:02:37.075] "Copy server to host" terminal command done

Notes

• It should not be possible to totally break connection to the remote unless scp is not installed.