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
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
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
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
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.
Problems Encountered on a Windows 8 System
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
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
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:
[Users] UserCount=1 [User0] Name=JDoe Auth=0 Password= Domain= Shell=1 SFTP=1 Tunnel=1
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:
09-02-2013 11:36:51 IP 192.168.2.10 SSH JDoe successfully logged on using password. 09-02-2013 11:36:51 Shell service granted to user JDoe. 09-02-2013 11:36:52 IP 192.168.2.10 SSH JDoe disconnected.
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
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.
Created: Monday, September 2, 2013