- VSCode Version: 1.40.2
- Local OS Version: Windows 10
- Remote OS Version: NAME="Red Hat Enterprise Linux Server";VERSION="7.7 (Maipo)"
- Remote Extension/Connection Type: SSH
Steps to Reproduce:
- Try to connect to a machine without proxy credentials with the Remote-SSH extension.
Does this issue occur when you try this locally?: Not applicable.
Does this issue occur when you try this locally and all extensions are disabled?: Did not try.
I have a target server that I am connecting to with Remote-SSH. Following wget's attempt to download the VS Code server, I receive an error:
[15:27:02.729] remote-ssh@0.47.2
[15:27:02.729] win32 x64
[15:27:02.733] SSH Resolver called for "ssh-remote+xxxx", attempt 1
[15:27:02.733] SSH Resolver called for host: root@TARGETHOSTNAME
[15:27:02.733] Setting up SSH remote "TARGETHOSTNAME"
[15:27:02.835] Using commit id "f359dd69833dd8800b54d458f6d37ab7c78df520" and quality "stable" for server
[15:27:02.839] Testing ssh with ssh -V
[15:27:03.053] ssh exited with code: 0
[15:27:03.054] Got stderr from ssh: OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
[15:27:03.060] Running script with connection command: ssh -T -D 14700 root@TARGETHOSTNAME bash
[15:27:03.063] Install and start server if needed
[15:27:03.068] Terminal shell path: C:\Windows\System32\cmd.exe
[15:27:03.980] >
[15:27:03.980] Got some output, clearing connection timeout
[15:27:18.409] > root@TARGETHOSTNAME's password:
[15:27:19.386] >
[15:27:28.166] >
>
[15:27:28.627] > 2ded42c88cfe: running
>
[15:27:28.701] > Acquiring lock on /root/.vscode-server/bin/f359dd69833dd8800b54d458f6d37ab7c78df520/vscode-remote-lock.f359dd69833dd8800b54d458f6d37a
> b7c78df520
> Installing to /root/.vscode-server/bin/f359dd69833dd8800b54d458f6d37ab7c78df520...
> Downloading with wget
[15:27:28.735] >
>
[15:27:35.670] > wget download failed
>
>
[15:27:35.705] > XDG_SESSION_ID=10
> SELINUX_ROLE_REQUESTED=
> SHELL=/bin/bash
> SSH_CLIENT=192.168.0.50 14706 22
> SELINUX_USE_CURRENT_RANGE=
> QTDIR=/usr/lib64/qt-3.3
> QTINC=/usr/lib64/qt-3.3/include
> QT_GRAPHICSSYSTEM_CHECKED=1
> USER=root
> VSCODE_AGENT_FOLDER=/root/.vscode-server
> PATH=/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
> MAIL=/var/mail/root
> PWD=/root/.vscode-server/bin/f359dd69833dd8800b54d458f6d37ab7c78df520
> LANG=en_US.UTF-8
> KDEDIRS=/usr
> SELINUX_LEVEL_REQUESTED=
> HOME=/root
> SHLVL=2
> LOGNAME=root
> QTLIB=/usr/lib64/qt-3.3/lib
> SSH_CONNECTION=192.168.0.50 14706 192.168.1.10 22
> XDG_DATA_DIRS=/root/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
> LESSOPEN=||/usr/bin/lesspipe.sh %s
> XDG_RUNTIME_DIR=/run/user/0
> QT_PLUGIN_PATH=/usr/lib64/kde4/plugins:/usr/lib/kde4/plugins
> _=/usr/bin/printenv
> OLDPWD=/root
> Trigger client server download
> VSCODE_ARCH==x64==
> 2ded42c88cfe__trigger_vscode_server_download__
> Waiting for client to transfer server archive...
> Waiting for /root/.vscode-server/bin/f359dd69833dd8800b54d458f6d37ab7c78df520/vscode-scp-done.flag and vscode-server-linux-x64.tar.gz
> to exist
>
[15:27:35.706] Got request to download on client for x64
[15:27:35.719] Resolver error: Failed to download VS Code Server: HTTP 407 - Proxy Authentication Required
[15:27:35.720] ------
I have the following as my settings.json:
{
"workbench.startupEditor": "newUntitledFile",
"editor.acceptSuggestionOnCommitCharacter": false,
"remote.SSH.allowLocalServerDownload": true,
"remote.SSH.showLoginTerminal": true,
"git.ignoreLegacyWarning": true
}
It appears that remote.SSH.allowLocalServerDownload is not being respected.
Why would this be? Is this option not honored in the case of a proxy failure as noted above?
Steps to Reproduce:
Does this issue occur when you try this locally?: Not applicable.
Does this issue occur when you try this locally and all extensions are disabled?: Did not try.
I have a target server that I am connecting to with Remote-SSH. Following
wget's attempt to download the VS Code server, I receive an error:I have the following as my
settings.json:It appears that
remote.SSH.allowLocalServerDownloadis not being respected.Why would this be? Is this option not honored in the case of a proxy failure as noted above?