CITATION (thanks to Micahel Hirsch), 90% of the content here is his content, I just am putting my edits into it as a NOTE TO SELF on how to setup SSH on Windows 8.1:

This will setup ssh server on your windows box (Windows 8.1 64 bit) so you can log in.

NOTE: after setting this up you can access your data on your hardrives by changing in to the directory /cygdrive/
If you had drive c and d, you will see /cygdrive/c and /cygdrive/d where your data exists.

NOTE: when you ssh in you will by in cygwin, not cmd, but cmd commands will work (because cmd commands work in cygwin, and you just sshed into cygwin – catch the drift)

Some terms that are lose:

* Server/Windows Server/Windows Box/ssh server/Windows SSH server – this is the windows box you installed cygwin on that you will be installing ssh server on. If I mention do a localhost connection. That means your sitting on this windows PC trying to connect to yourself using the hostname “localhost” or ip “”

* sshd – this is the name of the ssh server program

* Another PC / Client / ssh client / Remote machine- this is done by the program “ssh”

* sshd is the server program that listens for connections and sets up the bash sessions for users connecting in so that you can run commands on the Server from anywhere (even from localhost or a Client PC on the other half of the world, or a Client PC in the same room). ssh is the program that connects to sshd servers. Note there is more then just sshd servers out there, there is also openssh (which I think is the same program just with a different name – kind of like httpd and apache2 are the same program). But also there is dropbear which is an ssh server program (I dont believe dropbear has a Cygwin version of sshd though)

* user_ssh – this is the name of the user that I pick, it installs it as a windows and cygwin user but it will be used for connecting to the ssh server from remote/client machines. You can call it whatever I named it “user_ssh” you can call it “Mickey” for all I care.


STEP 1) run “setup-x86_64.exe” and install “openssh
NOTE: If you already installed cygwin and forgot to install openssh, just run that setup file and add openssh (it will only install openssh and openssh’s needed modules)

STEP 2) start Cygwin64 using “Run as Administrator” (Right click and select run as admin) and type “ssh-host-config” in the Cygwin terminal. (dont run “ssh-host-config -y” as that just answers yes to everything, but its good to set your answers)
STEP 3) here are some suggested answers to the configuration script questions:
(note can answer in lower case “yes” as well)
Priviledge separation? YES
* Question – What is this Priviledge seperation?
sshd as service? YES
value of CYGWIN for daemon? (just press Enter key, don’t type anything)
use a different name? no (you want to use cyg_server – this will be the user you log in to ssh with – when you “putty”/”ssh” into this computers sshserver)

NOTE: I put “yes” for different user. So if you want to use a different username for your ssh login. Which gave extra questions (setting username and password, and if the user will be priviledged – have acccess to everything or not, of course we put yes as we want root access for everything):
Enter the new user name: ANYUSERNAME  (example I picked user_ssh as you will see later in Step7 and 8)
Reenter: ANYUSERNAME (just pick any new name)
Create new privileged user account ‘ANYUSERNAME’? (yes/no) yes (just put yes we want this user to have all access, like root essentially)
Please enter the password: (pick a secure password)
Reenter: (pick a secure password)

STEP 4) in Cygwin64, type “cygrunsrv -S sshd

—If you get an error—
Get the error number from the output 1062 and 1069 are common. And just google “openssh cygwin Error number” and perhaps also append your windows version.

Also read the log file, it has the best info (without it I would of figured out my fix)
# cd /var/log/

NOTE: this folder /var/log is actually located in your /cygdrive/c/cygwin/var/log (so inside the cygwin folder is where all of the stuff on / is)

# cat sshd.log
Analyze errors or (TIP: empty log file “:> sshd.log” that will empty a file without deleting the file – it just removes the data in the file and makes it of size 0 bytes, so you wont need to recreate the file and worry about its attributes recreation, then run “cygrunsrv -S sshd” again to produce error and read log again “cat sshd.log” this way the only enteries are from this error)

—If error 1069—
If you get “system error 1069 has occurred. The service did not start due to a logon failure”, check the password on your “priviledged server” cyg_server — maybe you typed it wrong.

—If error 1062—

I put 2 fixes but more then 1 exist. So just google around. The answers are out there people.

* FIX#1 – Permissions of keys too open – *** THIS IS THE ERROR I EXPERIENCED AND I FIXED IT LIKE THIS ***
My error as read from sshd.log:
Permissions 0660 for ‘/etc/ssh_host_ecdsa_key’ are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh_host_ecdsa_key
Could not load host key: /etc/ssh_host_ecdsa_key
Disabling protocol version 2. Could not load host key
sshd: no hostkeys available — exiting.

FIX: Change the permissions to something less open and thus more secure so it wont cry.

# chmod 600 /etc/ssh*key*

NOTE: I used the * because I wanted to change every ssh key at once to the correct permissions

* FIX#2 – double cygwin1.dlls


Thanks, Your update was the resolution – for anyone else out there, there is a recipe #3 against Win32 error 1062 at Cygwin startup:
1) Check the Application Event log, see if there are “Information”-level events there with something like: “sshd: PID : Possible duplicate cygwin1.dll:”
Find that silly duplicate at the specified location and rename it or get rid of it from the path somehow. Mine was at “/cygdrive/c/Program Files (x86)/socat-”
Boo, socat! Apparently they engage in 3PP. Didn’t even know socat was on my system, apparently it came as a part of some other installation. I found 2 other people in the cygwin mailing lists having suffered from the duplicate-dll problem.
* Whats 3PP?

STEP 5) now try to login to your SSH server from another PC. Under services.msc you should see the Status “started” for service “CYGWIN sshd”, and under the General tab the “path to executable” should be something like
STEP 6) to configure your SSH server (optional), type in Cygwin64:
nano /etc/sshd_config
to make the changes take effect, type
cygrunsrv -E sshd
cygrunsrv -S sshd

Step 7 and Step 8 are troubleshooting errors that are by default in place do to Windows Security. Like enabling port 22 Inbound on the Windows firewall (if your windows firewall is disabled you shouldnt have this issue). The other issue is the user that was made (if you optionally decided to make a user like I did)

Try to connect from The Windows server:

ssh user_ssh@localhost or ssh user_ssh@

Try to connect from another PC to the The Windows server:

ssh user_ssh@windows_server_ip 


ssh user_ssh@windows_server_hostname

If Localhost works and Diff

STEP 7) Windows firewall will probably not allow connection on port 22. Symptom is ssh connection hangs from a different computer, but localhost connection works. So Try connecting to your server with “ssh user@windowsip” or “ssh user@windowshostname” from another machine. If it fails then try to disable Windows firewall and try again, if it works after that: Enable Firewall backup, Go to Advanced Firewall rules, and make a rule to always all TCP 22 inbound to any program (or to sshd if you want to be more secure)

STEP 8) Another issue at first you might experience is the error “Connection to <server name or ip> closed.” Thats after the firewall allows you in and etc. This means that your user that you made for ssh probably isnt allowed to start a bash session. Or his login session goes to /bin/false and you need to change it to /bin/bash. 

You can test if thats the case with doing a regular connection to bash with CYGWIN from your windows server:

su – user_ssh

That means start a login session with user user_ssh. Well guess what that also gives me the error “connection to … closed” So that means I need to edit my /etc/passwd


nano /etc/passwd

Find your user and change the very last bit that says /bin/false to simply /bin/bash

# Example – Before fix (got the error “Connection to closed “every time from localhost connection and from other computers):

# Before fix: this is a single line that says the shell of the user should be /bin/false which means that user will never be able to connect

user_ssh:unused:1012:513:Privileged server,U-ceo\user_ssh,S-1-5-21-3318719762-3177193176-3178453083-1012:/var/empty:/bin/false

# After fix:

user_ssh:unused:1012:513:Privileged server,U-ceo\user_ssh,S-1-5-21-3318719762-3177193176-3178453083-1012:/var/empty:/bin/bash

The connection should now work

4 thoughts on “SSH ON WINDOWS 8.1 PC VIA CYGWIN

  1. I am getting “connection closed by ::1” when doing ssh


    ssh -v localhost
    OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014
    debug1: Reading configuration data /etc/ssh_config
    debug1: Connecting to localhost [::1] port 22.
    debug1: Connection established.
    debug1: identity file /home/Manoj/.ssh/id_rsa type 1
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/Manoj/.ssh/id_rsa-cert type -1
    debug1: identity file /home/Manoj/.ssh/id_dsa type 2
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/Manoj/.ssh/id_dsa-cert type -1
    debug1: identity file /home/Manoj/.ssh/id_ecdsa type 3
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/Manoj/.ssh/id_ecdsa-cert type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/Manoj/.ssh/id_ed25519 type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/Manoj/.ssh/id_ed25519-cert type -1
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_6.7
    debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7
    debug1: match: OpenSSH_6.7 pat OpenSSH* compat 0x04000000
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-ctr none
    debug1: kex: client->server aes128-ctr none
    debug1: sending SSH2_MSG_KEX_ECDH_INIT
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    debug1: Server host key: ECDSA c5:c3:08:b6:b3:65:df:ee:2d:8d:f2:05:77:cb:91:be
    debug1: Host ‘localhost’ is known and matches the ECDSA host key.
    debug1: Found key in /home/Manoj/.ssh/known_hosts:1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: Roaming not allowed by server
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,password,keyboard-interactive
    debug1: Next authentication method: publickey
    debug1: Offering RSA public key: /home/Manoj/.ssh/id_rsa
    Connection closed by ::1

    Unable to sort this out, can you please guide on this?

    1. I apologize that didnt work. I would need to be at the system to fix it, there are too many variables. I hope there is other input. The steps above worked for me on a couple systems. I even looked over the steps again and repeated sometime later, so I followed the steps to the T and it worked. There might of been a recent update to cygwins ssh or windows security and maybe thats why its not working. It looks like perhaps it didnt like the public key offering, but I believe it should of said something like, I disagree with your key. Instead it just kicks you out. Put more -vvv

    2. I may have an idea why this may be happening and the workaround or fix…?

      Look in the registry for the below:


      Now find the SCHANNEL key and delete it.

      NOTE: Back it up first. Just in case there was something in there you actually needed!

      I have wrestled with this setting on a number of occasions with everything from RDP to HTML to you name it…

      My thoughts here, are that M$ decided to look into what the OpenSSL / OpenSSH community worked with—cipher stengths/weaknesses. In some cases like SSH there would be a need to “move” the ordering of cipher suites such as diffie-hellman or the likes in PuTTY for how the client and server would agree on what cipher to utilize during their handshake and login authentication process…

Leave a Reply

Your email address will not be published. Required fields are marked *