freeSSHd on Windows 8

If you want to set up a Windows 8 system as a Secure Shell (SSH) server, you can use freeSSHd, which as the name implies is free, to do so.

You can download freeSSHd.exe from the website for the software here. At the end of the installation process you will be prompted to create private keys; choose "yes" to create them. You will also be prompted "Do you want to run FreeSSHd as a system service?" Choosing "yes" will allow the system to start the SSH server whenever the system starts, so you won't need to start it manually. But, I found that with Windows 8, I could not get the software to allow me to consistently log in via SSH unless, I chose "no". That meant I would have to start the SSH service by clicking on the freeSSHd icon placed among the Windows 8 tiles or by clicking on the FreeSSHDService.exe file placed in its installation directory after any system reboot.

Once the installation is completed, you can change the settings for it to allow specified accounts to log into the system via SSH. If you don't see a freeSSHd icon in the notification area, aka the "system tray" on the Windows taskbar, you can find the freeSSHd icon among the Windows 8 tiles and click on it or start it by clicking on FreeSSHDService.exe in the installation directory for the software. Once it is there, you can right-click on it and choose "Settings" to change the settings for the program.

The SSH service should already be running, but if you see "SSH server is not running" in the Server status tab, you can click beneath that text to start the SSH service.

You can click on the Users tab to add the user accounts on the system for which you wish to allow SSH access.

To permit local accounts on the system to be used for logging into the system via SSH, click on the Add button and then put the userid for a local account in the Login field. Leave the Authorization field set for "NT authentication". For SSH access to a shell prompt from which you can run commands on the system, check "Shell".

To allow file transfers between the system and a remote system via the SSH File Transfer Protocol (SFTP), check the "SFTP" box. If you wish to allow the account to tunnel other types of connections through an SSH connection, i.e., you wish to permit port forwarding, check the "Tunneling" checkbox. If the account you will be using is an account that is local to the system on which freeSSHd is running, leave the "Domain" field blank. You would only use it for a domain account. Click on OK once you have completed the entries for the account.

If you wish to change the port on which the server listens for connections from the default of TCP port 22, click on the SSH tab, change the value in the port field and click on Apply.

If you wish to allow local port forwarding, i.e., you wish to allow remote users to tunnel other types of traffic, e.g., web traffic, through the SSH connection, click on the Tunneling tab, then check the box next to "Allow local port forwarding".

If you want to allow local port forwarding, but only to the localhost address of 127.0.0.1, you can also check the box next to "but forward only to localhost (127.0.0.1)".

When you are finished with making any settings changes, go back to the Server status tab and click on "Click here to start it" beneath "SSH server is not running." if the service is not yet running.

If you wish to confirm that the system is listening for connections on the default SSH port, or the one you selected, if you changed the port value, you can use the netstat and find commands from a command prompt. On Windows 8, you can get a command prompt by typing cmd at the Windows 8 interface and selecting "Command Prompt".

c:\>netstat -an | find "22"
  TCP    0.0.0.0:22           0.0.0.0:0              LISTENING

You should then be able to connect to the system from a remote system via SSH provided that any needed firewall rules are set. If you are using the Windows firewall or other firewall software on the system on which you are running freeSSHd, make sure you have set up an appropriate rule to allow incoming connections to TCP port 22, or whatever port you are using, if you changed the default port. For connections that are originating from outside an external firewall, or cable modem or router with builtin firewall capabilities, make sure you have configured that equipment to allow the incoming connections to the IP address for the system on which you installed freeSSHd.

If you are having problems when attempting to log in from a remote system, I'd recommend installing PuTTY on the system on which you installed freeSSHd and using it to test SSH logins from the system itself.

You can also turn on logging of events to aid in troubleshooting by clicking on the Logging tab and checking the "Log events" checkbox.

When I first installed the software and opted to "run FreeSSHd as a system service" during the installation process, I found that when I changed the default port through the graphical user interface (GUI) for the service that the service was then running on that port plus the default port of 22. And when I rebooted, the software was only listening on the default port. I checked the configuration file for freeSSHd, FreeSSHDService.ini, which is in the directory where the software is installed. It showed SSHListenPort=22, i.e., the default port even though I had changed it in the GUI. And despite the fact that I had used the GUI to allow SSH access for a local account on the system, the password was always rejected when I tried logging into that account via SSH.

I didn't see the icon for the service in the system tray and when I started FreeSSHDService.exe by double-clicking on it after I rebooted again, it showed "SSH server is not running" even though it was clearly running, since I could get a userid and password prompt when attempting to log in via SSH.

So I stopped the service from a command prompt, which you can get in Windows 8 by typing "cmd" then right-clicking on the icon for

Command
Prompt

and choosing "Run as administrator".

C:\Windows\system32>net stop FreeSSHDService
The FreeSSHDService service is stopping.
The FreeSSHDService service was stopped successfully.

I then restarted the service through the GUI and rebooted the system again, just to make sure I would still be able to login via SSH after rebooting the system. After rebooting, I was no longer able to login.

I noticed that the "Users" section of the FreeSSHDService.ini contained only the following lines.

I changed the UserCount value from 0 to 1 and added the following lines at the end of the file in that section:

Setting Auth=0 specifies NT authentication, i.e., the type of authentication used when you log into Windows. If you are logging into a local account then you don't need a value after "Domain=". I found later that, if you are using NT authentication, the password line will have 41 zeroes in it.

After stopping the service at the command line and then making changes through the GUI, I was able to log in successfully, but while trying to ensure that the service would work consistently across reboots, I later got to a point where freeSSHd appeared to accept my userid and password, but would immediately disconnect me after I provided them. When I checked the log file, I would see entries such as the following when that occurred:

Eventually, because I needed to move on to other tasks in setting up the system, I uninstalled it and reinstalled it without opting to run it as a service, which meant having to manually start the service after each reboot, but at least the service would then run and allow me to log in consistently.

It appeared that when I was running it as a service, that the GUI for controlling the software could not recognize that the service was running under the System account and that changes I made through the GUI weren't always being put in the FreeSSHDService.ini file, so weren't being retained after a reboot. I was using an account in the Administrators group and would even right-click on the FreeSSHService.exe application and choose to run it as an administrator when I started it, but that didn't allow me to resolve the problems when the software was running as a service.