I am trying to ssh into my remote server within the Windows 10 Linux Subsystem. I am using MS Windows 10 Home Insider Preview build 14366.

While at the command prompt, I type:

ssh [email protected]

A few seconds after typing the ssh command, I am getting the following message:

ssh: connect to host domain.com port 22: Resource temporarily unavailable

I am successfully able to connect using Putty as well as using ssh within Git Bash.

So, that leads me to believe the issue is on my local pc and more specifically within the Linux Subsystem. I'm still very green with the Linux environment and am not sure how to interpret this message. What resource is unavailable and what should I do to make it available?

  • First guess: Windows Firewall? ps> and welcome on superuser :) Google a little seems instead related with fork. Please edit the post and add the command line that give you this error.
    – Hastur
    Jul 8, 2016 at 16:26
  • related
    – Ramhound
    Jul 8, 2016 at 16:30
  • just checking that you are using an Insider Preview build of Windows 10 because AFAIK the Linux subsystem is only available in this version, not on 'normal' Windows 10. Otherwise maybe you are using Cygwin?
    – gogoud
    Jul 8, 2016 at 16:32
  • @ggoud - I have updated the question to include the operating system. It is indeed the Insider Preview build.
    – kell
    Jul 8, 2016 at 19:59
  • 2
    I am also having this issue. It affects all programs supported by ssh such as git and apt-get Aug 9, 2016 at 14:55

5 Answers 5


As far as I can tell, this is a bug in WSL. Hopefully, Microsoft will fix it in the next build. But for now, we can use this slightly ugly hack.

Update #1: Definitely a bug. Found this issue on Github. Thier proposed workaround of relaunching the shell works for me as well if you don't want to go through all of this.

TL;DR Add this to END your SSH config (usually located at ~/.ssh/config):

Host *
    ProxyCommand nc %h %p %r

Here's why it works: Our SSH issue is not a firewall issue because nc and telnet work to the same host and port (try telnet <host> <port> or nc <host> <port>: you should see something like SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7). This we can use to our advantage.

SSH allows the use of proxies that take standard input and send it to the server's port via the ProxyCommand option. This is normally used to tunnel into networks to a protected host by using an in-between bastion SSH server, sometimes called a jump host (see this link for more info).

This hack tells SSH to use a proxy with no jump host(s). So, it gets around SSH's failed allocation of TCP resources by pushing all of the network resource allocation onto Netcat, which does work. SSH just does its SSH thing without any network connections, and Netcat sends the raw data over a TCP connection to the SSH server.

WARNING: Since this modifies the ProxyCommand for all hosts, I do not know how it interacts with other SSH config hosts that use ProxyCommand. I have a few servers with which I can test this, and I will update this answer with the results. There is a chance that there are no detrimental side effects, but I cannot guarantee that.

Update #2: I did some testing with a few of my servers, and this appears to work. SSH uses the uppermost entry in the config when multiple entries apply. Thus, an existing ProxyCommand present above this hack would override it. When the new SSH command is executed, it re-reads the SSH config, and if there is no other ProxyCommand, SSH uses our hack ProxyCommand, allowing it to only apply to the "outermost" SSH session. Word of warning: if you put the hack at the top of the config file (or above the entry you are trying to SSH to), SSH sessions that require a ProxyCommand will ignore the other ProxyCommand and instead attempt to resolve the address of the host and connect directly with Netcat.

  • Thanks for the detail @computergeek125. Unfortunately, even after setting up the config as suggested, I still get the same message ssh: connect to host domain.com port 22: Resource temporarily unavailable When I run nc -v <host> <port>, for verbose output, I get the same error: Resource temporarily unavailable. I may be doing something wrong, not sure. Since I don't have any ssh issues using the Git bash shell, I'll stick with it for now. BTW, my system is now at build 14393, so, if this was a bug in the version at the time of the question, it is still a bug 27 builds later.
    – kell
    Aug 21, 2016 at 14:58
  • Well that's interesting. I'll have to do some research on that build. I was running 14903 at the time (I'm up to 14905 now). It may be something they fixed in the build I have. Aug 22, 2016 at 15:27
  • How do i edit the SSH config? In the bash for windows console I tried vi ~/.ssh/config which opened an empty file. I pasted your commands but when I try to save (esc -> : -> wq) it tells me "~/.ssh/config" E212: Cannot open file for writing
    – Dan
    Jan 10, 2018 at 10:55
  • Ok that's weird. What build of Windows are you running, and what's the output of ls -al ~/.ssh? Jan 10, 2018 at 12:31

This was also an issue for me, turned out it was my (Symantec) firewall blocking all internet traffic from bash.

Seems it's a general issue with 3rd party firewall providers which don't recognise the process:


When I disabled my firewall it worked okay. Can't find a better solution at the moment.


For future reference, when you install Nginx, it will block SSH by default with the error message "Resource temporarily unavailable" unless you...

sudo ufw allow ssh

  • Windows 10 itself has a firewall. Why did you suggest that?
    – Biswapriyo
    Feb 23, 2019 at 17:52
  • I'm suggesting that for future users with the same problems because I had the exact same issue and it was because Nginx was blocking SSH to the server
    – andrerpena
    Feb 23, 2019 at 18:10

In my case, I got this error because a windows update caused trouble with my Hyper-V switch. Turns out the host I was trying to ssh to was connected to that switch--fixing it restored ssh.


I faced the same problem suddenly after ssh was working fine, then I found that windows made an update which affected my Hyper-V virtual switch configuration .. somehow after some trails I was able to fix it mainly by disabling and removing one of the Hyper-V virtual switches added after the windows update

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .