87

I use vscode with remote-ssh to connect my server, after configuring, I want to connect my host, but it failed, the dialog box display:"could not establish connection to XX, The process tried to write to a nonexistent pipe."

output:

[16:45:20.916] Log Level: 3
[16:45:20.936] remote-ssh@0.49.0
[16:45:20.936] win32 x64
[16:45:20.944] SSH Resolver called for "ssh-remote+aliyun", attempt 1
[16:45:20.945] SSH Resolver called for host: aliyun
[16:45:20.945] Setting up SSH remote "aliyun"
[16:45:21.012] Using commit id "c47d83b293181d9be64f27ff093689e8e7aed054" and quality "stable" for server
[16:45:21.014] Install and start server if needed
[16:45:21.019] Checking ssh with "ssh -V"
[16:45:21.144] > OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
[16:45:21.214] Running script with connection command: ssh -T -D 5023 aliyun bash
[16:45:21.221] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[16:45:21.504] > 
> 
>
> ]0;C:\WINDOWS\System32\cmd.exe
[16:45:21.505] Got some output, clearing connection timeout
[16:45:21.577] > 
> 
>
> 
[16:45:21.592] > Bad owner or permissions on C:\\Users\\DY/.ssh/config
> 
[16:45:21.689] > The process tried to write to a nonexistent pipe.
> 
[16:45:22.091] "install" terminal command done
[16:45:22.092] Install terminal quit with output: The process tried to write to a nonexistent pipe.
[16:45:22.093] Received install output: The process tried to write to a nonexistent pipe.
[16:45:22.096] Resolver error: The process tried to write to a nonexistent pipe
[16:45:22.107] ------

Gonçalo Peres
  • 11,752
  • 3
  • 54
  • 83
douyu
  • 2,377
  • 2
  • 14
  • 27
  • In case of multiple hops [adding the full path of the ssh executable to the `ProxyCommand` option in the `.ssh/config`](https://stackoverflow.com/a/61365780/7259176) worked for me. – upe Nov 07 '20 at 15:19

32 Answers32

106

Add the absolute file path to a custom SSH config file(C:\Users\{USERNAME}\.ssh\config), and my problem is solved.

enter image description here

douyu
  • 2,377
  • 2
  • 14
  • 27
  • 4
    In addition to this I had to add the new host and then connect to it. Just connecting to the host didn't work. – bones.felipe Jun 03 '20 at 17:51
  • 5
    how did you get to that screen of "remote ssh etc" shown in your answer? – yishairasowsky Jun 10 '20 at 09:26
  • 12
    @yishairasowsky `crtl+shift+p` and enter remote-ssh: settings. – douyu Jun 10 '20 at 10:46
  • This actually broke things further when I tried it. Now it does not even get to the part making the OP's errors. I get the following error in VSC: Command 'Remote-SSH: Connect to Host...' resulted in an error (EISDIR: illegal operation on a directory, read) - I checked permissions and I have full control. When I revert, the OP error returns. – user3507825 Aug 28 '20 at 23:12
  • 6
    try to delete the known_hosts file too. Or edit to remove the server fingerprint – TecHunter Oct 22 '20 at 18:49
  • check also the id_rsa or id_ed21559 file. mine was badly exported by puttygen – TecHunter Oct 22 '20 at 18:56
  • 2
    Why exactly would this help? It didn't fix anything for me. – aviator Jan 27 '21 at 18:13
  • Ok, resolved now. For future visitors, there may be multiple reasons -- mine was that I was trying to point the SSH config "IdentityFile" flag (i.e. private key) to a PuTTY file (.ppk extension), whereas it should be an OpenSSH file (typically no extension) instead. – aviator Jan 27 '21 at 18:20
  • Also check the syntax of your config file - in my case there was auto-generated `usekeychain` that is used my macOS and wasn't recognized by my Windows host. VSCode won't tell you about that but if you try to ssh using PowerShell, you'll get the error message. – Pramus Feb 22 '21 at 08:49
  • This is the only solution that has worked for me. Thanks. In addition to this, I also deleted ```known_hosts```, ```config``` files in local computer and on server the ```.vscode-server``` directory. – Mycodingproject May 19 '21 at 20:49
  • It works! Created a config file. Added path in settings as described. Ctrl+P (Windows) command pallet & typed `>Remote SSH: Connect to host...` Selected +Add New SSH Host. Entered the full SSH command. Added to the config file. And VSCode connected asked for the pw. – Dami Jul 05 '21 at 12:10
  • as a note on how this could happen: the GitPod local companion extension changed the config path from the correct setting to some temporary file and didn't revert it back. That's why my hosts couldn't be found anymore – jemand771 Oct 05 '21 at 08:02
  • In the "PROBLEMS" pane of VSC, it showed what was causing the failure. In my case, I'm connecting to a guestVM (running locally) and its hostkey changed. The complaint told me the line number (19) that was failing in hostkeys. The solution was easy -- I used an editor (notepad++) to remove the offending line. I then invoked "Remote SSH: Connect to host"), selected the host, and accepted the new hostkey it offered. This solved my problem and left all my other connections unbroken. – Tom Stambaugh Oct 21 '21 at 17:01
  • 1
    I don't understand why this worked. After setting the config file path, I added a host, and it added another entry to the same config file. It was already using that config file. It seems like nothing changed. I actually made a typo in the new host and then deleted the one I just added and used the old config. Literally nothing changed except that I told it to use the path that it was already using. This is voodoo. – ADJenks Dec 24 '21 at 18:23
  • 1
    @ADJenks I don't understand why either but it worked using the same config as before. Seems like a odd bug to me. – mab0189 Dec 08 '22 at 11:10
46

If you format/re-install Server OS, but use same IP as before, you may encounter fingerprint mismatched.

You may need to delete old fingerprint in this file: C:\Users\xxx.ssh\known_host

and old IP in the file: C:\Users\xxx.ssh\config

Then try to add host again.

Night Owl
  • 461
  • 4
  • 2
12

What worked for me:

  1. delete ssh config folder both in C:\Program Data\ssh and C:\<user>\.ssh
  2. In VS Code, press F1, choose Remote-SSH: Connect to Host...
  3. Do NOT enter anything in the prompt, but instead choose + Add New SSH Host..
  4. Enter the full ssh command, including the key (in case of Windows, you may want to enclose the path with double quote mark) ssh -i "C:\path\to\key" user@host. (you need to make sure the key has a limited permission. Remove all inherited permissions, and only give a full control to the owner.)
  5. You will be asked to choose a folder in which a new config file will be created. Choose any of the two options.
  6. There will a prompt notifying that the new config file has been created. Click connect
Leonard AB
  • 1,479
  • 1
  • 19
  • 30
  • This should be the accepted answer. Thank you! – angryweasel Jul 22 '21 at 03:38
  • Step 4 for worked for me (https://superuser.com/questions/1296024/windows-ssh-permissions-for-private-key-are-too-open). Bizarre because it was working perfectly fine for ages. Then suddenly started kicking off about permissions being too open! – zenzone Sep 15 '21 at 03:03
  • 1
    This destroys ALL the connections! There is an easier way. In my case, the issue was caused by a hostkey that changed. The "PROBLEMS" pane reported the failing entry in hostkeys (line 19). I used notepad++ to remove that line. I then invoked "Remote SSH: Connect to host" and selected the failing host. This time, it prompted me for a hostkey and invited me to accept it. Once I accepted the hostkey, all was fine. – Tom Stambaugh Oct 21 '21 at 17:03
  • @angryweasel: I don't think this should be the accepted answer, because it destroys all the existing connections. For those of us with many (at least six in my case), that's a serious flaw. – Tom Stambaugh Oct 21 '21 at 17:06
  • 1
    In step 1 `config` is a file not a folder. – Mike Poole Jan 20 '23 at 10:45
9

At least three things may be happening:

Option 1

The location of your config file is not the absolute location, meaning you are probably using the location of the folder where the config file is.

If that is the case, access your User Settings in VSCode. Scroll to the Extensions>Remote - SSH. And add config at the end of the absolute file path of your custom SSH config file. In Windows, it can be

C:\Users\user\.ssh\config

See image below

enter image description here


Option 2

Authentication problems.

If that is the case, one of the things that may solve is generating new SSH keys.

In Windows, for that, I recommend using MobaXterm.

In MobaXterm, open a new terminal and write

ssh-keygen -b 4096 -t rsa

Then, in the config file, make sure that the IdentityFile points to the location of the key. MobaXterm's home directory, usually, is C:\Users\user\Documents\MobaXterm. If it makes it easy, one can copy/move the keys to C:\Users\user\.ssh and then just add, in the config file, IdentityFile ~/.ssh/KEY_rsa (where KEY_rsa is the name of the [public] key).

Note that if you use PuTTY to generate the keys, on the server OpenSSH authorized_keys file, one doesn't want the public key that one saves, but the one that appears on top (see image bellow):

enter image description here


Option 3

Your config file may be wrong.

The config file tends to look as follows. Double check if the fields have the information needed for the connection to be established.

Host Test # This is the name we want to give the host
    User user # This is the username
    Hostname blabla.com # This is the hostname
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/KEY_rsa # This is the location of the key
    IdentitiesOnly yes
    Port 50    # This varies
Gonçalo Peres
  • 11,752
  • 3
  • 54
  • 83
6

What worked for me was to delete all of the contents of folder: C:\Users\MYNAME.ssh That meant to delete both the config file and known-hosts. The config was probably the most important one to delete.

dalilander
  • 139
  • 3
  • 4
    Deleting a whole config directory or file is very representative of a "i don't know what i'm doing" behavior. You just had to delete the conflicting line from `known_hosts`, and of course before that, double check that your remote host was not getting impersonated. – NdFeB Mar 11 '21 at 13:57
  • 1
    @NdFeB When there is 10 differents anwsers and none of them work, i'm pretty sure nobody knows what they are doing. My solution was.. to restart my computer -__-' – Eta Oct 26 '21 at 14:32
4

The solution in my case was editing the json settings file for VSC as shown here: https://code.visualstudio.com/docs/remote/troubleshooting#_troubleshooting-hanging-or-failing-connections In VSC go to File, Preferences, Setting and click on the upper right hand icon (Open Settings, JSON). Add these two lines to settings.json and retry connecting:

"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false
kaba11
  • 41
  • 2
3

In my case I had another setup:

  • Git bash in Windows was configured and I am using the ssh.exe provided by this tool
  • In the "Remote SSH" extension in VSCode, I specified the full path of this ssh.exe
  • I am using multiple servers (with ProxyJump)
  • The error message is the same as the OP but in the logs it was written that the ssh config file was not found, where all the folder names was concatenated (because it did not recognize the windows path separator)

Problem: the ssh.exe is using a different path convention thant VSCode. ssh.exe is using the "/c/Users/..." pattern and VSCode is using the "C:\Users..." pattern.

Solution:

  1. Make sure the SSH config is at a standard place (C:\Users\LOGIN\.ssh\config)
  2. Remove the absolute path of the config file in the "Remote SSH" settings in VSCode

VSCode will still be able to access the settings using the standard path, and the ssh.exe configuration will still look at the same standard path so the connexion is working.

Note:

I have the error only when connecting with multiple ssh servers (using ProxyJump). When connecting only to the first server, the solution of @pszrux and this one are both working for me.

mountrix
  • 1,126
  • 15
  • 32
  • I had the exact same problem, and ended up with the same solution by trying all sorts of different settings changes. Thanks for the confirmation that this is the working solution. I wish I read this about 45 min ago. – Mark Rajcok Oct 02 '21 at 05:09
3

This is probably something everyone has tried before looking here, but it worked for me. The server I was trying to ssh into was not responding, leading to the nonexistant pipe error. I rebooted the server and everything worked fine.

David Kaftan
  • 1,974
  • 1
  • 12
  • 18
2

OS: windows 10

In my case there were permission issues. Repeatedly changing inheritance in windows did not solve the issue. Finally this worked

change the folder in which the config file is stored. From C:/users/usr/.ssh/config to D:/config and changed the configenter image description here path in vscode remote ssh settings.

This worked for me.

2

This seems to be a problem with varied causes and corresponding remedies. In my case the problem had to do with the version of ssh I was using. In my Windows path there were two places were an instance of ssh.exe resided:

C:\Program Files (x86)\OpenSSH\bin
C:\WINDOWS\System32\OpenSSH\

After using both paths to set the "Remote.SSH: Path" parameter (which is in "Remote.SSH: Settings" [see here]), i.e. first C:\Program Files (x86)\OpenSSH\bin\ssh.exe and then C:\WINDOWS\System32\OpenSSH\ssh.exe, the problem still persisted.

Then I looked at this and tried the git-provided ssh.exe, which I already had on my system (otherwise, just install git, it's good stuff anyway :) )

Setting the SSH path parameter with that version did the trick for me, i.e. setting path to:

C:\Program Files\Git\usr\bin\ssh.exe

zerzevul
  • 417
  • 5
  • 11
  • I ran into a problem like that described by this answer. My issue was caused by using the ssh `ProxyJump` feature in my config file to connect to some of my remote systems. It turns out that the Microsoft version of `OpenSSH` _does not_ support the `ProxyJump` feature (Sep 2021), but the `Git for Windows` implementation of `OpenSSH` _does_ support the `ProxyJump` feature. So pointing to the Git for Windows version fixed things for me, as well. I think a recent update of Git for Windows on my system caused the order of those two instances of `ssh.exe` to be reversed in the PATH. – xmnboy Sep 07 '21 at 16:59
2

For Windows:

Adding the escape character before the private key file name & using quotes around the path solved my issue.

//config file

Host 12.12.12.12
  HostName 12.12.12.12
  IdentityFile "C:\Users\USERNAME/\PRIVATEKEY" <----Note /\
  User username
dev07
  • 346
  • 2
  • 8
2

In my case, I did what dalilander said, but instead of deleting the entire '.ssh' folder, I just needed to delete the file 'known_hosts' and then it worked. So the servers I had saved were not deleted.

The path of that folder is C:\Users\yourUsername\.ssh

  • 2
    Deleting a whole config directory or file is very representative of a "i don't know what i'm doing" behavior. You just had to delete the conflicting line from `known_hosts`, and of course before that, double check that your remote host was not getting impersonated. – NdFeB Mar 11 '21 at 13:54
2

I had this problem once.

All you need to do is,

  1. Go to /Users/XXX/.ssh

  2. if you are on the windows, use command : "del /f known_hosts" to delete the known_hosts on the command prompt.

3.Then go to C:\Users\XXX.ssh\config on the vs code( config file )

4.Delete the host and the user if the host that you are trying to connect to is already there.

5.Then try to connect to the new host as usual.This will work.

The problem here could the mismatch of the finger prints once you reinstall the OS o n your host machine. So to solve this problem by deleting the host that was saved.

once the config file on the vs code is edited it should look like..below picture is to show how the config file should look(after deleting the host saved)

Tarun M
  • 31
  • 2
1

Trying to add the full path in "IdentityFile" made the trick

" IdentityFile C:\Users\xxx.ssh\xxx"

neus
  • 15
  • 2
  • 6
1

The solution below may be the last resort but it perfectly solved the issue for me in a Windows 10 local machine. I simply delete the known_hosts file under the directory C:\Users\[your-username]\.ssh, relaunch VS Code and reconnect the remote server through Remote Explorer. Everything works normally afterward.

Li-Pin Juan
  • 1,156
  • 1
  • 13
  • 22
1

This seems to be a general error when the ssh connection fails for one of a multitude of reasons.

Adding what my issue was, and what helped, because I don't see it in the other answers in here: I had re-installed the box I was connecting to, and with it, reset the key it was using to authenticate. The ssh process tried to connect and failed with the usual "someone might be MITMing you this very moment, the identification changed" error, visible in the VSCode terminal. Solution was to go to my authorized_keys file and remove the offending key.

Obviously only know that if you know for sure why the identification changed, and that it's harmless. Don't actually get MITMed.

1

If you're using WSL and might think that you should update ~/.ssh/config, that might not be the case.

  1. Copy the content from ~/.ssh/config
  2. Append it to C:\User\xxx\.ssh\config windows file
  3. Make sure the public/private key is on C:\User\xxx\.ssh\ and is listed in config
  4. Reconnect
go je jo
  • 311
  • 4
  • 8
0

Had an existing(working) configuration and had the same error when I added a new one. What worked for me is instead of just adding a new host configuration, I also commented out the first working config. Didn't know what happened but it worked.

Kelvin Barsana
  • 824
  • 12
  • 28
0

In my case this was an offending key in my known_hosts in Windows (vscode on windows, remote developing via ssh on linux).

The error that comes back in vscode is not explaining in any way.

Jos
  • 1,387
  • 1
  • 13
  • 27
0

In my case, the path to key file was wrong.

Sergey Romanov
  • 2,949
  • 4
  • 23
  • 38
0

For me, (windows) the permissions on the .pem file were the Critical issue. I had Administrator group only on the pem file and it was not working. I had to explicitly add the Admin user as well (even though admin is of course in administrator group).

0

In my case, I had no internet connection.

I was connecting to the server via VPN but the remote configuration was incorrect and I couldn't access the server. (DNS related issues) The connection indicator was showing no errors, so I didn't think of that at first.

Oops :)

lsu
  • 71
  • 1
  • 4
0

I really didn't want to delete my C:Users\valo\.ssh\config, so I played a little with the various entries. It turned out that for me the option IdentitiesOnly yes was the problem. I also disabled security inheritance on all key files in the .ssh folder and left only myself, with Full Rights. Here is what my C:Users\valo\.ssh\config looks like now:

CanonicalizeHostname yes

Host aws.r3
  HostName 3.31.45.216
  ForwardAgent yes
  User ubuntu
  IdentityFile C:Users\valo\.ssh\u1-client-20210203-090555.pem
  # IdentitiesOnly yes    # VSCode Remote doesn't like this flag...?

Host github
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_val_ed25519

Host github.vm
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_valo_ed25519

Host *
  ForwardAgent yes
  AddKeysToAgent yes
  LogLevel FATAL
  ChallengeResponseAuthentication no

Now I can connect to aws.r3 with VSCode Remote.

Valo
  • 1,872
  • 2
  • 15
  • 23
0

A possible solution:

First run cat $HOME/.ssh/id_rsa.pub on your computer. That will get you a key. Save this key somewhere.

Then open this file by running vim $HOME/.ssh/authorized_keys on the computer that you're are ssh'ing to. Then copy the key in a new line of this file and close it by typing :wq.

You are all set.

John
  • 11
  • 1
0

In my case it was because the name I gave the host in config was myuser@myhostname. So if your config file looks like this:

Host myuser@myhostname
    HostName 12.64.88.234
    User myuser
    Port 22

Try changing it to this:

Host myuser
    HostName 12.64.88.234
    User myuser
    Port 22
jdgregson
  • 1,457
  • 17
  • 39
0

Mine was solved by adding ".pem" extension while specifying the private key. Here's the sample config text for reference.

Host ec2-3-234-8-176.compute-1.amazonaws.com
  HostName ec2-3-234-8-176.compute-1.amazonaws.com
  IdentityFile ~/.ssh/privatekey.pem
  User username
Patrick Prakash
  • 500
  • 1
  • 7
  • 17
0

There can be several reasons that have nothing to do with the accepted answer. For me:

  1. Ubuntu 14.04.1 LTS didn't seem to work
  2. Issues with EC2 auth, see pem file config and pem file permissions
citynorman
  • 4,918
  • 3
  • 38
  • 39
0

And for yet another seeming cause/solution:

  • Adding the config path explicitly to settings only caused an EISDIR error.
  • Removing the listing from known_hosts made it need to confirm the fingerprint, but it didn't provide a way to do that. I could see it trying in the terminal output.
  • The solution a coworker recommended was to delete the vscode-server files from the server. That was the key step in my case. But...

Connecting to the server using another client, I attempted to rm -rf ~/.vscode-server. I could not delete many of the files because "device or resource busy".

That eventually required doing the following:

  1. fuser ~/.vscode-server/[one of the child files ...]. But, you can probably skip this, because mainly I needed to know what to search for. Plus, fuser and lsof were finicky about returning results -- they often just sit waiting for something, I don't know what.
  2. ps -e | grep node since node is the running process using vscode-server files.
  3. For each PID in the list of node processes from step 2, run ps -o user= -p PID, substituting PID with each process PID in turn. This creates a formatted list of the process's associated user.
    This is to determine which node processes you own, so you're not even trying to kill anybody else's.
  4. Starting with the lowest node PID I own, run kill -9 PID. You won't need to run this for all PIDs, because killing a lower PID killed a child PID after a few seconds. So keep checking which node processes still exist after killing one: ps -e | grep node
  5. Finally, once all mine are killed, I can rm -rf ~/.vscode-server
  6. Then, I was able to connect via ssh in VS Code again. And, since I left the fingerprint removed from known_hosts, it even asked to confirm the connection to the server (up top, in the command prompt).

Also, for reference, I left the remote-ssh: settings config file entry, mentioned in other solutions, blank.

For reference or further explanation of certain steps above (I don't intend to elaborate more than I did):

rm: cannot remove ‘.vscode-server/bin/xxxxxx/.nfs000000000xxxxxxxxxxxx’: Device or resource busy

How find out which process is using a file in Linux?

https://unix.stackexchange.com/questions/284934/return-owner-of-process-given-pid/284938

GG2
  • 179
  • 10
0

In my case it worked when I added the port in my expression, eg ssh user@host-or-ip -p 22. With '22' the default port number, but you can check which port the ssh system is listening on with the sudo service ssh status command.

0

WSL Related

In my case, the issue was that my keys were set up on Ubuntu on WSL and VS Code was looking for them in Windows. I copied the keys over from the WSL side to Windows and voila! Worked like a charm!

Steps that I took.

  1. Navigated to the /home//.ssh folder in WSL and then entered explorer.exe .
  2. From there, I copied the id_rsa and id_rsa.pub files and pasted them in the windows side, under C:\Users<username>.ssh
  3. Then I tried connecting again from VS Code and it worked perfectly.
Dharman
  • 30,962
  • 25
  • 85
  • 135
0

Novice coder here. I had this problem "process tried to write to a nonexistent pipe." Tried various changes to VS Code, EC2 instance, and deleted known_hosts file. Turns out I was getting "access denied" because day before I had added another user to my username as a linux group (I was learning how Groups works). When I removed the other user from the group ("$gpasswd -d user2 user1"), my ssh issues were resolved.

0

Make sure you have ssh-server installed on the server you want to connect to.

sudo apt update
sudo apt install openssh-server

I successfully wasted my 4 hours because of it.

sha'an
  • 1,032
  • 1
  • 11
  • 24