VSCode Remote SSH Connection Failed
Asked Answered
F

17

25

I'm trying to use the Remote-SSH extension to edit files on a Debian server. The SSH connection is established correctly but then I get an error message :

Failed to connect to the remote extension host server

And the log :

[13:19:04.182] Remote server is listening on port 51569
[13:19:04.182] Parsed server configuration: {"agentPort":51569,"osReleaseId":"debian","arch":"x86_64","webUiAccessToken":"","sshAuthSock":"","tmpDir":"/tmp"}
[13:19:04.184] Starting forwarding server. localPort 59828 -> socksPort 59825 -> remotePort 51569
[13:19:04.185] Forwarding server listening on 59828
[13:19:04.185] Waiting for ssh tunnel to be ready
[13:19:04.186] Tunneled remote port 51569 to local port 59828
[13:19:04.186] Resolved "ssh-remote+home-debian.web-data.host" to "127.0.0.1:59828"
[13:19:04.187] [Forwarding server 59828] Got connection 0
[13:19:04.195] ------
[13:19:04.208] [Forwarding server 59828] Got connection 1
[13:19:04.208] [Forwarding server 59828] Got connection 2
[13:19:04.217] Failed to set up socket for dynamic port forward to remote port 51569: Socket closed. Is the remote port correct?
[13:19:04.227] > channel 3: open failed: administratively prohibited: open failed
[13:19:04.235] Failed to set up socket for dynamic port forward to remote port 51569: Socket closed. Is the remote port correct?
[13:19:04.237] Failed to set up socket for dynamic port forward to remote port 51569: Socket closed. Is the remote port correct?
[13:19:04.241] > channel 4: open failed: administratively prohibited: open failed
> channel 5: open failed: administratively prohibited: open failed

I am using the remote ssh connection on several other servers and have never had this error. I have tested a few things gleaned from the web but nothing has worked so far.

Could someone enlighten me on the reason for the problem or on a possible solution ? Thanks !

Fossilize answered 3/3, 2020 at 12:52 Comment(1)
For me the host key verification failed, but I set strict host key checking to false. VSCode always reported the error that port forwarding is disabledBenefit
B
33

Changing AllowTcpForwarding from no to yes in sshd_config and restarting sshd works for me.

Tested on Raspbian GNU/Linux 10 (buster)

Beulabeulah answered 23/7, 2020 at 10:51 Comment(2)
tested on debian 9, there is a section: AllowAgentForwarding no, in /etc/ssh/sshd_config, but I only changed the AllowTcpForwarding no to yes, it works! thank you very much!Witchery
You just saved my life in a project for a client !!!! Thanks !!!Amazonas
P
26
Delete '~/.vscode-server' folder on your server, and try reconnect.

Not sure for Debian server, but this worked on Ubuntu 18.04

Poss answered 21/5, 2020 at 6:23 Comment(5)
Rather than provide a speculative answer, it would be better to provide one that you've tested and know is effective (on Debian), or perhaps has been confirmed by someone else.Deeply
Thanks -- I've had at least two occasions where Remote-SSH with VSCode either became completely inoperable, or was working incorrectly, and this solved it. I cannot say as to why it worked, and I would like to understand it better. In the latter situation of "working incorrectly", it seemed to not be running my ~/.profile, and after removing a ~/.bash_profile I no longer needed, new remote sessions weren't picking up the ~/.profile, but after killing the remote vscode-server and removing ~/.vscode-server folder, it came back and now is working as desired.Terrorstricken
Not sure why, but this worked on Ubuntu 18.04.Signorelli
Could you explain in more details how to do this ? Where should I type it ? what should I replace?Comprehensive
Still working on Amazon Linux 2023.Croupier
S
20

Follow these steps

  1. Update the sshd_config file in the host machine.Follow this command nano /etc/ssh/sshd_config and then set AllowTcpForwarding to yes
  2. Restart ssh on the host machine sudo systemctl restart ssh
  3. Detele the .vscode-server in host machine rm -rf /home/<user_name>/.vscode-server
  4. Now connect through VS Code again. Hopefully it will work
Shornick answered 17/8, 2021 at 10:22 Comment(1)
how can I make this work on Mac os?Ectomy
T
15

When having root access to host

Ensure AllowTcpForwarding yes is set in the remote host's /etc/ssh/sshd_config file.

If you don't have root access to host

You can use a sshd run as a normal user with a different configuration, allowing vscode to create forwarded ports.

The goal is to have a user controled sshd server started with AllowTcpForwarding yes and then use ssh's ProxyCommand to connect to this server.

The steps to do this are:

  1. Setup a sshd server (https://serverfault.com/a/946877):
    • Create working dir in home
    • generate server keys in the working dir
    • generate basic config file with pid file located in the working dir
    • launch SSH daemon
    • If you get errors about PAM, you can try with UsePAM no
mkdir ${HOME}/custom_ssh
ssh-keygen -f ${HOME}/custom_ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f ${HOME}/custom_ssh/ssh_host_dsa_key -N '' -t dsa

cat << EOF > ${HOME}/custom_ssh/sshd_config
Port 2222
HostKey ${HOME}/custom_ssh/ssh_host_rsa_key
HostKey ${HOME}/custom_ssh/ssh_host_dsa_key
AuthorizedKeysFile  .ssh/authorized_keys
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PasswordAuthentication yes
UsePAM yes
X11Forwarding yes
Subsystem   sftp    /usr/lib/ssh/sftp-server
PidFile ${HOME}/custom_ssh/sshd.pid"
EOF

/usr/bin/sshd -f ${HOME}/custom_ssh/sshd_config
echo "----- Process ID : ${HOME}/custom_ssh/sshd.pid -------"
  1. On your client PC, configure a ssh host in ~/.ssh/config:
Host RemoteHost
    HostName 127.0.0.1
    Port 2222
    User user
    ForwardAgent yes
    ForwardX11 yes
    ProxyCommand ssh user@RemoteHostIp netcat %h %p
  1. Use RemoteHost host in vscode

The resulting ssh path is like this:

interactive ssh <= stdio => ProxyCommand's ssh <= network => JumpHost's sshd <= stdio => netcat <= network => RemoteHost

SSH network path

See also: https://www.cyberciti.biz/faq/linux-unix-ssh-proxycommand-passing-through-one-host-gateway-server/

Tacky answered 30/4, 2022 at 18:23 Comment(0)
I
2
[13:19:04.227] > channel 3: open failed: administratively prohibited: open failed

The remote server that you're connecting to is refusing to perform port forwards for you. Assuming the remote server is OpenSSH, there are two places on the remote server where this might be configured:

  1. The server may be configured not to permit port forwarding through the sshd_config options PermitOpen or DisableForwarding options.
  2. If you're authenticating with an ssh key, forwarding might be disabled through the authorized_keys options PermitOpen or restrict.
Indictable answered 3/3, 2020 at 13:48 Comment(1)
Thanks for help ! I think it's because I do not use the root user to connect to the ssh server. Could the problem be that ?Fossilize
A
2

I was getting this error:

Could not establish connection to "workspace": Port forwarding is disabled.

I was getting this error because my remote host vm had been rebuilt causing my known_hosts file on the local system to contain an invalid key. Removing the old entry from known_hosts solved the issue.

Antitype answered 14/1, 2022 at 16:55 Comment(0)
G
2

In my case, the ssh host identification had changed - I was seeing this message when ssh-ing to the remote host:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

The fix was to resolve this issue first - see answers to ssh remote host identification has changed for details

ssh-keygen -R <host>
Gramicidin answered 4/3, 2022 at 0:28 Comment(0)
R
2

In Brief

You can try to disable SELinux to solve this problem. On Centos 7, the command is as follows:

Temporarily disable

> getenforce
  Enforcing
> setenforce 0 # Change from Enforcing to Permissive
> getenforce
  Permissive

Diable even after restart

> sed -i 's/enforcing$/disabled/g' /etc/selinux/config 
  # Auto close SELinux after reboot

Solving Process

I just solved this problem, to help people who are in the same predicament as me, here is my solution on CentOS 7. (Maybe a little different from above answers).

I got the error message below when I tried to connect my server by VScode Remote SSH:

00be3d8293b0: start
SSH_AUTH_SOCK====
DISPLAY====
webUiAccessToken====
listeningOn==44128==
osReleaseId==centos==
arch==x86_64==
tmpDir==/run/user/10053==
platform==linux==
unpackResult==success==
didLocalDownload==0==
downloadTime==2533==
installTime==10009==
extInstallTime====
serverStartTime==556==
connectionToken==2256a5b5-f1c8-4290-8446-576967b6a8a0==
00be3d8293b0: end
channel 3: open failed: administratively prohibited: open failed
channel 3: open failed: administratively prohibited: open failed

After searching many blogs, I tried to edit /etc/ssh/sshd to ensure the following code appears in the file:

PermitOpen any
AllowTcpForwarding yes

I restarted the sshd to make sure the file change takes effect. But it didn't work for me.

systemctl restart sshd
(for me here is systemctl restart sshd.init)

Then I tried to find some error messages from journalctl -f, and I found that everytime I try to connect server by VScode, the following errors will appear (It happens when Vscode try to use wget):

sshd[14761]: error: connect to 127.0.0.1 port 44128 failed: Permission denied
sshd[14761]: error: connect to 127.0.0.1 port 44128 failed: Permission denied

Permission denied reminded me that it may be related to SELinux, so I changed the state of SELiunx:

> getenforce
  Enforcing
> setenforce 0 # Change from Enforcing to Permissive
> getenforce
  Permissive

Then miraculously, the problem was solved.

And to ensure SELinux will not take effect after reboot, I executed the following command:

> sed -i 's/enforcing$/disabled/g' /etc/selinux/config 
  # Auto close SELinux after reboot
Rosary answered 1/4, 2022 at 15:39 Comment(0)
A
1

FWIW; I had the same issue and a reboot seemed to solve the problem.

Aguie answered 21/11, 2020 at 16:20 Comment(1)
I concur. There are cases for me where the connection breaks in the middle of a coding session, and then attempts to restart VSCode result in the remote connection hanging, or result in a successful connection but failure to sync the workspace. The server side daemon can definitely hang too, ssh config is only part of the story. Restarting the remote host can indeed fix certain things.Endamage
U
1

In my case it was a VM running on my local and I bring it down and up with Vagrant. This makes the identification to change so often and therefore just removing the host entry from known_hosts in my localhost made the trick.

Ussery answered 26/8, 2022 at 13:21 Comment(0)
P
1

Assuming you have no root access, here is a solution based on Alexis Murzeau's answer, which works in environments where there is a server in a cluster but its users lack root access and AllowTcpForwarding is disabled.

This solution involves creating an SSH tunnel through a public cloud virtual machine. Therefore, please only use it if you understand its security implications and consider additional security measures (e.g. limiting the IP ranges that can access the cloud instance).

As prerequisites for this solution, you must be able to:

  • Start a cloud instance in AWS EC2, GCP, Azure, etc. (any small instance, e.g. an EC2 free-tier instance, works).

  • Start an SSHD process on your cluster machine without root access.

  • Open an SSH tunnel from your cluster machine. (Certain SELinux rules can prevent you from doing this.)

The following is an overview figure with your local computer (where the VS Code desktop application runs), the cloud instance (used as a proxy), and the cluster machine (where you'd like to run VS Code server but cannot enable AllowTcpForwarding for the default SSH process).

Overview

The steps to configure this setup are the following. Values between guillemets, e.g. «cloud_instance_username», must be substituted according to your configuration.

  1. Start a cloud instance (e.g. with Ubuntu 22.04).

  2. SSH into the cloud instance and configure its SSHD to enable AllowTcpForwarding:

    sudo vim /etc/ssh/sshd_config
    

    Uncomment the line: AllowTcpForwarding yes

    Restart the SSH service with:

    sudo service sshd restart
    
  3. Add the public SSH keys of your local computer and of the cluster machine to the ~/.ssh/authorized_keys file on the cloud machine.

  4. Setup an SSHD server on the cluster machine:

    mkdir ${HOME}/custom_ssh
    ssh-keygen -f ${HOME}/custom_ssh/ssh_host_rsa_key -N '' -t rsa
    ssh-keygen -f ${HOME}/custom_ssh/ssh_host_dsa_key -N '' -t dsa
    
    cat << EOF > ${HOME}/custom_ssh/sshd_config
    Port 2222
    HostKey ${HOME}/custom_ssh/ssh_host_rsa_key
    HostKey ${HOME}/custom_ssh/ssh_host_dsa_key
    AuthorizedKeysFile  .ssh/authorized_keys
    ChallengeResponseAuthentication no
    PubkeyAuthentication yes
    PasswordAuthentication yes
    UsePAM yes
    X11Forwarding yes
    Subsystem   sftp    /usr/lib/ssh/sftp-server
    PidFile ${HOME}/custom_ssh/sshd.pid"
    EOF
    
    /usr/bin/sshd -f ${HOME}/custom_ssh/sshd_config
    echo "Process ID file: ${HOME}/custom_ssh/sshd.pid"
    echo "Process ID: $(cat ${HOME}/custom_ssh/sshd.pid)"
    

    If you want to kill this SSHD server later, run:

    kill $(cat ${HOME}/custom_ssh/sshd.pid)
    
  5. On the cluster machine, create a reverse SSH tunnel to the cloud instance. Note that this command stays in the foreground. Use tmux to keep the session open or the -f flag to run it in the background.

    ssh -R 8081:localhost:2222 \
      «cloud_instance_username»@«cloud_instance_ip_address»
    
  6. On the local machine, test the access with:

    ssh -J \
      «cloud_instance_username»@«cloud_instance_ip_address» \
      «cluster_machine_username»@localhost -p 8081
    
  7. If this works, edit the ~/.ssh/config file on your local computer:

    Host proxy_cloud_instance
        HostName «cloud_instance_ip_address»
        User «cloud_instance_username»
    
    Host vscode_ssh_host
        HostName localhost
        User «cluster_machine_username»
        Port 8081
        ProxyJump proxy_cloud_instance
    
  8. Test the SSH configuration by issuing:

    ssh vscode_ssh_host
    
  9. Try starting a remote SSH session in VS Code to vscode_ssh_host.

Perseverance answered 3/9, 2022 at 10:0 Comment(0)
C
1

I had an entirely different issue, after the above solutions failed to address my issue I read the error log more carefully. It has a message, which is now gone saying something along the lines of

host key verification failed

after which it proceeded to disable a number of functionalities including port forwarding.

In my case, the solution was to delete my local known_hosts file located at,

C:\Users\username\.ssh\known_hosts

that being said this could cause issues with your ssh configurations more broadly so better practice would be to remove only the host_key which has been invalidated.

Case answered 7/9, 2023 at 21:46 Comment(0)
R
0

"I'm trying to use the Remote-SSH extension to edit files on a Debian server"

Before this answer gets massively downvoted, it should be recognised that VS Code supports far simpler ways of editting files on remote servers and I think this answer will help some people. IMHO it is reasonable to answer a question "how do I use X to do Y" to at least suggest there might be a better X.

IF you only want to edit files on a remote linux server then a VS Code extension such as "ftp-simple" only requires you have logon credentials to the server and an sftp server is running there. This is a traditional low-impact way of providing the remote filesystem semantics an editor requires (browse file system, get file, save file) which can be fairly seamlessly integrated into the usual editor workflow.

remote-ssh is intended to be far more feature rich, requiring an application-specific protocol over an ssh tunnel between 'VS Code' executables at both ends, which itself requires VS Code to bootstrap the installation of VS Code 'server' code on the remote server for the connection to work. If you require features over-and-above the basic file-io necessary for browsing and editting files (for example remote testing, compilation and debugging) then remote-ssh will be a good choice.

Ropable answered 6/9, 2022 at 13:41 Comment(0)
B
0

just allow tcpforwarding from NO to YES and run this : sudo /etc/init.d/ssh restart

Work perfect for me Good luck !

Bender answered 27/12, 2022 at 18:21 Comment(1)
This is already proposed here, how does your answer improves on it?Etymon
U
0

None of the above solutions work for me. In my case, I have an AWS EC2 dynamically created every day with the same public DNS. The SSH Remote only works for the first time and not thereafter. After deleting the known host file sudo rm ~/.ssh/known_hosts, I was able to connect again.

Unsteel answered 20/2, 2023 at 1:57 Comment(0)
D
0

In my case, the resolution was just to ensure the https proxy connection in my local machine so that the client can download the updated plugin via https.

The remote sshd's AllowTcpForwarding was 'no', but it didn't appear to be the reason. And also the other solutions didn't work. The following logs were shown in the remote window's output and I thought 'locally' was about the server, but I realized it was about the client.

[11:18:09.071] Got request to download on client for {"platform":"linux","arch":"x64","destFolder":"/home/mabox/.vscode-server/bin/6445d93c81ebe42c4cbd7a60712e0b17d9463e97"}
[11:18:09.073] Downloading VS Code server locally...
[11:18:11.452] Resolver error: Error: XHR failed
    at y.onerror (vscode-file://vscode-app/c:/Users/xxxxxx/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:77:1261)
[11:18:11.462] ------

Here are the details FYI.

  • client: windows 10 pro 19045.3208
  • vscode: version 1.81.0
  • server: mabox linux 23.07
Drunkard answered 7/8, 2023 at 2:59 Comment(0)
M
0

Changing the IP address of the host resolved the issue for me. VS Code was able to configure all settings automatically in this case. It seems that a different host was previously associated with this IP. The problem has been resolved.

Menses answered 28/4 at 12:4 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.