I have Windows 10 Anniversary Edition with "Bash on Ubuntu on Windows" installed and working. I'd like to be able to SSH into this Ubuntu instance, but although I have openssh-server installed and configured (and listening on port 2200), when I try to ssh to "localhost:2200", it tells me "Server unexpectedly closed network connection".

Has anyone been able to successfully accomplish this?

enter image description here

  • Using Process Hacker and looking at the 'Network' tab, it shows sshd (running on Ubuntu on Windows 10) is listening on the 2200 local port. – Mick Aug 9 '16 at 15:08
  • and if you try to connect to the ip address of the system? Ubuntu often maps loopback addresses differently than windows does, and uses additional values in (often – Frank Thomas Aug 9 '16 at 15:29
  • @Ramhound: Not true. Localhost is localhost and everything is shared. You can perfectly well do links http://localhost/ from the Linux subsystem and see the web page provided by IIS on Windows side. There is no separation. – Sami Kuhmonen Aug 9 '16 at 16:48
up vote 101 down vote accepted

I got it to work; here's how.

Uninstalled ssh-server, reinstalled it and made sure it's started with

sudo service ssh --full-restart

Make sure you turned off root access and added another user in the config file.

I was able to connect to the subsystem on as expected.  I hope this will help you.

Here's a screenshot.

  1. sudo apt-get purge openssh-server
  2. sudo apt-get install openssh-server
  3. sudo nano /etc/ssh/sshd_config and disallow root login by setting PermitRootLogin no
  4. Then add a line beneath it that says:

    AllowUsers yourusername

    and make sure PasswordAuthentication is set to yes if you want to login using a password.

  5. Disable privilege separation by adding/modifying : UsePrivilegeSeparation no

  6. sudo service ssh --full-restart

  7. Connect to your Linux subsystem from Windows using a ssh client like PuTTY.

  • 2
    i didnt have to do that - strange.. but remember this is still in beta stage so results may vary – Master Azazel Aug 17 '16 at 21:26
  • 7
    Additionally I had to: Stop/Disable Windows 10 SSH Server Broker Services from the services control panel and set: PubkeyAuthentication no in the sshdconfig – math0ne Sep 16 '16 at 3:49
  • 6
    I also needed to add a firewall rule. There was an existing rule, but that was only for the Windows SSH Server Proxy, and when I stopped that service, the firewall blocked traffic on port 22. – Pierre-Luc Paour Sep 29 '16 at 8:54
  • 2
    I also had to change ports (Port 2222 in /etc/ssh/sshd_config file), if not the ssh server of windows picked up the connection on port 22. – arod Jan 13 '17 at 2:12
  • 2
    @ArtemRussakovskii they stop the whole Linux subsystem whenever you close the bash window... – Sakher Jul 20 '17 at 22:16

Since windows implementation doesn't provide chroot you need to modify the /etc/ssh/sshd_config

UsePrivilegeSeparation no

Also you will need to create a user using useradd command or so.

  • 4
    This step was essential in getting it to work. – Mick Aug 17 '16 at 20:27
  • 1
    I was curious, so I found this at freebsd.org/cgi/man.cgi?sshd_config(5): UsePrivilegeSeparation: – krs013 Sep 1 '16 at 7:46
  • Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The argument must be "yes", "no"', or "sandbox". If UsePrivilegeSeparation is set to "sandbox" then the pre-authentication unprivileged process is subject to additional restrictions. The default is "sandbox". – krs013 Sep 1 '16 at 7:46
  • 6
    WSL implemented chroot in September 2016 (after this answer). – GreenReaper Apr 28 '17 at 8:21

The by-committee answers above were great. Thank you for them. And while they came super close, I still had Connection closed by problems.

I found and added additional steps from this post which got me over the hump. In particular, starting over and adding this as the initial/first step (notice the --purge qualifier), finally resolved my variation of this issue:

sudo apt-get remove --purge openssh-server
sudo apt-get install openssh-server
sudo vi /etc/ssh/sshd_config # Change Port from 22 to 2222 (Just in case MS-Windows is using port 22; which, by the way, SSH on MS-Windows can be disabled if you want to use port 22).
sudo service ssh --full-restart

Thanks again, I hope this addition helps others. =:)

  • 2
    Why the downvote? These instructions alone didn't work in my case, as mentioned, and the additional step above worked. I don't get it. – prismalytics.io May 16 '17 at 4:54
  • 1
    I was having a very different error "No supported authentication methods available (server sent: publickey)" and these steps fixed it. – Mike Viens Sep 2 '17 at 11:52
  • 1
    For some reason, Windows just didn't appreciate that I was running on Port 2222. It didn't ever show any other processes using it, and there was no evidence of port conflict, but as soon as I changed ports, it began to work. – forresthopkinsa Jan 11 at 2:16

I did everything as Master Azazel suggested and had the problem. When I connected to port 22 I was asked for a password, but the password I set in the Linux subsystem didn't work.

Solution #1:
change the SSH port in /etc/ssh/sshd_config and restart the SSH server in the subsystem

Solution #2:
disable/stop the "SSH Server Broker Services" in services control panel of Windows and restart the SSH server in the subsystem.

  • This only applies if you have something running on windows on port 22. – Master Azazel Dec 4 '16 at 10:14
  • 3
    Ofcz, as you see on my default installation of win10 there was a service running on 22... – scotty86 Dec 5 '16 at 11:47

The reason why you cannot ssh to it is shown in the logging from the server:

chroot("/var/run/sshd"): Function not implemented [preauth]

The Linux subsystem doesn't seem to have chroot implemented and the ssh server needs it so the connection is not allowed.

  • 2
    Which is correct.. but the other answers explain how to work around the chroot requirement. – Mahmoud Al-Qudsi Dec 12 '16 at 20:46

protected by Community Feb 4 '17 at 22:12

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.