What is SSH? SSH is a protocol that uses public key cryptography to transfer data securely over insecure networks.
Introduction
If you want to access remote servers securely from Windows 9x, NT, ME, 2000 or XP and don't want to pay for programs that are freely available for UNIX-like platforms, you may find this document useful. It describes free SSH implementations for Windows.
Although this document concentrates on Windows-specific implementations, much of the content, particularly relating to Port Forwarding and Authorized Keys, applies to any SSH implementation, regardless of the platform. VPN technologies, (including IPSEC), are discussed in passing, but these are not the main focus.
Email me, fitz@jfitz.com, if you find better implementations, or if you think there's anything I can add here. Please note that I will only include references to products that are available free of charge, and I have a strong preference for open source implementations.
For more links to SSH tools for Windows, (and Mac), I'd recommend trying the OpenSSH Windows/Mac pages: http://www.openssh.com/windows.html, or http://www.openssh.com/macos.html.
What is SSH?
SSH is a protocol that uses public key cryptography to transfer data securely over insecure networks. At the core of most SSH implementations are the "ssh" and "scp" commands.
"ssh" and "scp" are "secure" versions of the UNIX "rsh" and "rcp" commands, (which in turn are a bit like the more familiar "telnet" and "ftp" programs). The "ssh" command provides command-line, (non-GUI), access to a remote server. "scp" allows files to be copied to/from a remote server. Both programs use the SSH protocol to establish a secure connection and to encrypt all data passing between the client and the server.
What is "Port Forwarding" or "Tunneling"?
In addition to the direct access provided by the "ssh" and "scp" commands, the SSH protocol includes a feature called "Port Forwarding", or "Tunneling". This can be used to provide secure access to other services that do not normally encrypt data during transmission.
For example, to receive email, many email programs use the (unencrypted) POP3 protocol to connect to a mailserver on port 110. If we can SSH to the mailserver before downloading our mail, we can configure the SSH session to "forward" port 110 through the encrypted SSH link. Now, if we configure our email client to connect to port 110 on our local machine it will in fact be connecting to the remote mailserver, but all the data, (i.e. our incoming email), will be transferred over the encrypted SSH link.
If we also forward port 25, (which normally handles SMTP, the outgoing email protocol), then both incoming and outgoing email will be encrypted.
If you are mainly interested in securing your Windows email client, you could try jumping straight to my step-by-step guide to configuring a PuTTY SSH client for port forwarding email traffic.
Any number of ports can be forwarded in a single SSH session. For example, we could also forward port 80, (HTTP), to provide secure access to a corporate webserver. In effect, it is usually possible to create a pretty good approximation to a VPN, (Virtual Private Network), just by forwarding a handful of common ports, and using scp, (or WinSCP), to transfer files. In fact, a VPN is roughly equivalent to an SSH session where everything is being forwarded over a single secure channel.
Should I use SSH or a VPN?
If you are trying to decide between SSH and a VPN, I find that SSH is generally appropriate in situations where occasional remote access is needed to specific services, (for example, checking email, downloading files). If persistent access to a wide range of services is required, (for example, working exclusively on a corporate network while telecommuting), then a VPN is probably a better choice.
One of the problems with a VPN is that both the client and server need to be customized for the VPN to work, whereas most modern UNIX-like servers will provide SSH access by default when a user account is established, (so only the client PC needs configuring). A second problem is that traditional VPNs tended to be difficult to configure correctly, particularly on the server-side. However, solutions such as OpenVPN, (http://openvpn.net), are much easier to install and configure than many of the more traditional, IPSEC-based VPN solutions, so if you have administrative (root) privileges on the server it may be worth exploring OpenVPN. A VPN may require more work initially to get running on the server, but it will ultimately provide more flexibility on the client.
PuTTY
PuTTY, (and its file transfer utility, pscp), are excellent Windows ssh/scp implementations, and are a piece of cake to get up and running.
Download putty.exe and pscp.exe here: http://www.chiark.greenend.org.uk/~sgtatham/putty/, and you're ready to go. These programs are not zipped and do not require any installation.
When you run PuTTY, a configuration screen is presented first. It's a good idea to play with the configuration until you get colors, fonts and other settings that suit you. You can then give the session a name and save it, so it's easy to restore these settings next time you run PuTTY, (just double-click the stored session name). This process can be a little awkward because you need to exit and restart PuTTY to update a stored session, but once you have a good set of settings saved, you can use that session as a template to create other stored sessions for different host machines.
To help you get up and running with PuTTY, I've created a step-by-step guide to configuring a "typical" PuTTY session, (including port forwarding for incoming/outgoing email). You can check it out here: http://www.jfitz.com/tips/putty_config.html
When you first connect to a new machine using PuTTY or pscp, they will give you a message to indicate that they don't recognize the machine. Choose "OK" to add the machine to the list of known hosts and to continue connecting.
PuTTY works a bit like an xterm. If you highlight text with the mouse it is automatically copied to the clipboard. A right-click of the mouse will paste the copied text at the command-line cursor position. Right-click anywhere on PuTTY's Title Bar, (or left-click on the PuTTY icon in the top left corner), to access a menu where the current session settings can be changed.
To remove PuTTY automatically, run "putty -cleanup", (without the quotes). To do the job manually, delete the files you downloaded and use regedit to remove all the keys under
HKEY_CURRENT_USER->Software->SimonTatham->PuTTY.
WinSCP
WinSCP provides an easy-to-use graphical interface to "scp" functionality. It creates an SSH link to the remote server, then displays local and remote files in "Explorer-like" windows. Copying files securely to/from the remote machine is as simple as dragging and dropping, (or cutting and pasting), files in the WinSCP windows.
As of version 3, WinSCP also supports SFTP, ("secure ftp"). Unless you specifically need to use SFTP, it's probably as easy to stick with SCP -- the basic WinSCP functionality handles many of the issues that SFTP was designed to address.
You can download WinSCP here: http://winscp.net/eng/
WinSCP starts with a configuration screen and can save session settings in a manner that is very similar to PuTTY.
As of version 3, WinSCP includes a "Cleanup" option that allows you to remove any possibly sensitive settings that may have been created on your computer. With version 2, to remove WinSCP delete WinSCP2.exe and, to clean up the registry, use regedit to remove all the keys under
HKEY_CURRENT_USER->Software->Martin Prikryl->WinSCP 2.
WinSCP is released under the GPL. The source code is available for download with the application. WinSCP is partly based on PuTTY code, (it is usually pretty up-to-date -- check the WinSCP site for version details).
pscp
pscp is a companion program of PuTTY. It is a pretty straightforward Windows implementation of scp. It's a command-line program only, so you need to run it in an MS-DOS window.
The basic format of a pscp command, (or any scp command for that matter), is:
pscp myusername@remotehost:remotefilespec localfilespec
...to download from remotehost to your local machine, or:
pscp localfilespec myusername@remotehost:remotefilespec
...to upload to remotehost from your local machine.
Type pscp with no arguments for a list of other parameters that can be supplied on the command line.
Tera Term Pro/TTSSH
Another good terminal emulation package that supports SSH is Tera Term Pro. You can download it here: http://hp.vector.co.jp/authors/VA002416/teraterm.html
Tera Term Pro comes with a regular Windows setup program. As with PuTTY, I'd recommend changing the terminal settings to suit your preferences. Save the setup as teraterm.ini to replace the defaults.
By default, Tera Term Pro does not include SSH. For this, you need to download the SSH extension, TTSSH. The original download site was here: http://www.zip.com.au/~roca/ttssh.html, but this doesn't seem to be accessible any more. You can try the following mirror instead: http://public.planetmirror.com/pub/ttssh/, (the required file is ttssh154.zip).
Unzip this file in the same directory that Tera Term Pro is installed in. It adds a program called ttssh.exe. Run this program in place of Tera Term Pro itself, (ttermpro.exe), and you should now have SSH available as an option during connect. Additionally, you will find that some SSH options are added to the Setup menu. You may wish to change the defaults so that SSH, (on port 22), is the default connection method.
Tera Term Pro with TTSSH used to be the best free SSH implementation for Windows, but, in my opinion at least, recent versions of PuTTY have surpassed them for ease of use and improved functionality. You may wish to try both and draw your own conclusions.
Command line/X Windows - Cygwin/OpenSSH
If you're happiest working in a UNIX-like command-line environment, and are already familiar with the "ssh" and "scp" commands, you may want to try Cygwin, (http://www.cygwin.com/). Cygwin is a pretty complete GNU based, (i.e. UNIX-like), environment for Windows.
If you don't want/need the full Cygwin UNIX-like environment, OpenSSH for Windows, (http://sshwindows.sourceforge.net/), is basically a "cut-down" version of Cygwin which includes command line ssh/scp/sftp functionality. It also includes ssh/sftp servers, and it has a fairly straightforward Windows installation program. (Note that OpenSSH for Windows replaces the older, and no longer maintained, Network Simplicity OpenSSH server solution, http://www.networksimplicity.com/openssh/.)
If you do choose Cygwin, and you are comfortable working in the X-Windows environment, in addition to the rich selection of GNU command-line programs, (including sshd, ssh, scp and sftp), there are also Cygwin ports of XFree86, (http://cygwin.com/xfree/), KDE, (http://kde-cygwin.sourceforge.net/), and Gnome, (http://cygnome.sourceforge.net/). While this is no substitute for dual-booting with a good Linux distro or BSD release, it is handy for doing quick X-Windows work on a server without needing to reboot your Windows machine. I haven't used Cygwin's X-Windows tools extensively, but I have noticed that the quality and stability seems to be improving with each new release.
Known Hosts
The "known hosts" list contains the public keys of host machines that you "trust" when using ssh or scp. All implementations of ssh/scp, (including PuTTY, WinSCP and TTSSH), will give warnings if you are connecting to a new machine that is not in the list of known hosts. In addition, they will refuse to connect if the host's public key does not match the stored value.
PuTTY stores the list of known hosts in the registry, under the key:
HKEY_CURRENT_USER->Software->SimonTatham->PuTTY->SshHostKeys.
WinSCP also stores the known hosts in the registry, under the key:
HKEY_CURRENT_USER->Software->Martin Prikryl->WinSCP 2->SshHostKeys.
Tera Term Pro stores its list of known hosts in the following file:
C:\"Program Files"\ttermpro\ssh_known_hosts
(assuming the program was installed in the default folder).
If a host machine's public key is legitimately changed, (as part of an upgrade for example), you will need to remove the old key from the file, (or the registry in the case of PuTTY or WinSCP), to successfully connect to that host. You should, of course, be 100% sure that the key was genuinely changed, and that this is not a hacker's machine masquerading as the host -- this is why these keys are stored and checked in the first place.
Automatic login
With any of the installations covered so far we can only establish an SSH connection provided we supply a password each time. It is possible to automate SSH connections by generating "passphrase-less" secure keys and modifying our connection settings to use the new keys. In general, I would only recommend this procedure if you have a specific requirement for automating file transfers, and you clearly understand the security implications.
Keys can be generated on the Windows client-side, using PuTTYGen, or on the server-side, using ssh-keygen. Either program will generate a public key file and a private key file. Different key file combinations can be generated for different SSH protocol versions. If you specify a blank "passphrase", then only the key files will be required to authenticate the connection, thereby allowing unattended connections. (If you include a passphrase you will benefit from a "doubly-secure" authentication, based on both the key and the passphrase.)
To use the keys, save the key files in a secure location on the client machine. Then copy the contents of the public key file into the file $HOME/.ssh/authorized_keys, (SSH protocol version 1), or $HOME/.ssh/authorized_keys2, (SSH protocol version 2), on the server machine. Finally, modify the PuTTY, WinSCP or TTSSH session details so that it uses the saved private key file, (making sure it also uses the correct protocol for the specified key). You will find the option to specify the Private Key File under the SSH settings.
Assuming you've got the right files in the right places, and the correct session settings, when you attempt to connect you should find that you can connect without supplying a password or passphrase.
If you are using Cygwin and the command-line ssh/scp versions, you can check the man pages for ssh to determine where you need to save your key files so that the ssh and scp commands will connect without requiring a password/passphrase.
This "passphrase-less" approach is reasonably secure, provided access to the client machine is restricted. However, if someone manages to steal your private key file, (which might not be that difficult on most Windows machines), your server account will be fully compromised.
SSH Servers
The following is a brief introduction to SSH server software for Windows.
Cygwin, (http://www.cygwin.com), includes a port of the OpenSSH server software. Cygwin is basically a GNU, (UNIX-like), subsystem that runs on 32-bit Windows. To get SSH support for Cygwin, install the "openssh" package in addition to the basic Cygwin packages.
If you have any problems installing and configuring Cygwin "by hand", you could also try http://sshwindows.sourceforge.net/. This implementation basically wraps Cygwin's OpenSSH port in a package that includes a standard Windows installation program.
If you have concerns about running open source secure services, such as OpenSSH or OpenVPN, on Windows, the main alternative is the IPSEC functionality that comes built-in to Windows 2000 servers. IPSEC is fully supported by Microsoft, and Windows-compatible implementations are also available for most *nix. This seems intuitively more secure, since it involves fewer components that are not integral parts of the Windows O/S.
You could also use Windows Terminal Services. This has built-in encryption and has the advantage that it gives you GUI access. You might want to use this in conjunction with IPSEC if you have any concerns about the Terminal Services encryption algorithms.
If you prefer open source solutions, it is still possible to get secure remote GUI access to a Windows server using freely available software. VNC, (http://www.realvnc.com/), provides remote GUI access to Windows machines, and it uses predictable port assignment, so a VNC client session can be port-forwarded over an SSH link provided the Windows server is running an SSH server, (in addition to the VNC server).
I believe it is also possible to port-forward a Terminal Services client session over SSH -- the server appears to use port 3389 by default according to the following Microsoft support article: http://support.microsoft.com/default.aspx?scid=kb;en-us;150543.
Old Versions of this Document
The previous version of this document, (which you may find useful if you are using older versions of Windows SSH utilities), is available here: http://www.jfitz.com/tips/ssh_for_windows_doc_version2.html.
Summary of Links in this Document
OpenSSH Windows page: http://www.openssh.com/windows.html
OpenSSH Mac page: http://www.openssh.com/macos.html
OpenVPN, an open source, SSL VPN solution: http://openvpn.net
PuTTY, pscp and related tools: http://www.chiark.greenend.org.uk/~sgtatham/putty/
Configuring PuTTY: http://www.jfitz.com/tips/putty_config.html
WinSCP: http://winscp.net/eng/
Tera Term Pro: http://hp.vector.co.jp/authors/VA002416/teraterm.html
TTSSH, (Tera Term Pro SSH extension): http://www.zip.com.au/~roca/ttssh.html
TTSSH, (mirror site): http://public.planetmirror.com/pub/ttssh/
Cygwin: http://www.cygwin.com/
XFree86 for Cygwin: http://cygwin.com/xfree/
KDE for Cygwin: http://kde-cygwin.sourceforge.net/
Gnome for Cygwin: http://cygnome.sourceforge.net/
OpenSSH for Windows: http://sshwindows.sourceforge.net/
Microsoft's Terminal Services Advanced Client FAQs: http://www.microsoft.com/windows2000/techinfo/administration/terminal/tsacfaq.asp
Microsoft Terminal Services TCP port support article: http://support.microsoft.com/default.aspx?scid=kb;en-us;150543
VNC - Remote GUI access for Windows: http://www.realvnc.com/
Revision History
Version 1.0 22 June 1999 - Initial document
Version 2.0 22 January 2001 - Revised format, rewrote much of the content
Version 2.1 7 February 2001 - Added section on ssh servers
Version 2.2 16 November 2001 - Added notes on PuTTY port forwarding and Cygwin
Version 2.3 3 December 2001 - Removed link to commercial software
Version 2.4 6 December 2001 - Added section on WinSCP
Version 2.5 28 January 2002 - Added link to PuTTY configuration guide
Version 3.0 30 January 2002 - Rewrote much of the content
Version 3.1 6 March 2002 - Started Questions and Answers section, (ftp solution)
Version 3.2 27 March 2002 - Added psftp question/answer
Version 3.3 8 April 2002 - Added tunneling HTTP question/answer
Version 4.0 23 April 2002 - Revised format
Version 4.1 11 May 2002 - Expanded SSH server section, reintroduced Revision History
Version 4.1.1 15 May 2002 - Added links to Cygwin packages: XFree86, KDE and Gnome
Version 4.1.2 17 July 2003 - Updated WinSCP links
Version 4.2 25 May 2004 - Edited and updated links
Version 4.2.1 8 July 2004 - Mentions PuTTY's "-cleanup" option
Version 4.2.2 21 March 2005 - Updated WinSCP links
Version 4.2.3 29 March 2006 - Added link to OpenVPN
Questions and Answers
Question:
Subject: FTP solution
I have a school PC running Windows NT terminal server on Citrix on Red Hat and Windows NT server 4.0 at home. I have next to no access at school, and can't install anything, but I can access HTTP (and SSH via a computer on the edge of the firewall). What I want to do is copy files from home, through the firewall, to and from school. Is this possible using a GUI? If not is it possible another way? How?
Answer:
You can use WinSCP to do exactly what you describe. It uses the SSH protocol to transfer files, and provides an "Explorer-like" GUI for dragging/dropping files.
If you can SSH directly to the internal box through the firewall, then WinSCP will work "as-is".
If not, then you need a little bit of port-forwarding to get where you want to go:
Log onto the firewall, (or the machine that is directly accessible via the firewall), using SSH, forwarding an arbitrary local port to port 22 on the internal machine.
When you run WinSCP connect to "localhost" on the arbitrary port you selected.
For example:
Say "schoolfirewall.myschool.edu" is your school's firewall, (or the machine that is visible outside the firewall).
From "schoolfirewall.myschool.edu", you are trying to access a machine called mypc.myschool.edu", (which is not visible outside the firewall).
You (randomly) pick port 2200 as the local port to forward.
Create, (and save), a PuTTY session that connects to "schoolfirewall.myschool.edu" using SSH, with Local Forwarding of port "2200" to "mypc.myschool.edu:22", (specified in the "SSH Tunnels" section).
Before running WinSCP, run PuTTY using the saved session, (this will connect to the firewall with port 2200 forwarded - you must leave PuTTY connected for the duration of the WinSCP session).
Run WinSCP. Connect to "localhost" on port 2200. This will in fact be connecting to the SSH server on port 22 of "mypc.myschool.edu".
Provide the appropriate login details for "mypc.myschool.edu", and you should now be able to drag/drop files to/from the internal machine.
Notes:
"mypc.myschool.edu", (the internal server), needs to be running an SSH server. Red Hat should have that installed by default. You can also get a version for Windows if you need it, (see the section on SSH Servers).
If Local Forwarding to "mypc.myschool.edu:22" doesn't work, try using the internal IP address of the machine instead - it's possible that your client or the firewall can't resolve the internal address. For example, if "mypc.myschool.edu" is at IP address "10.0.2.100", try forwarding to "10.0.2.100:22".
Question:
Subject: psftp
Why not use psftp, (PuTTY's implementation of sftp)?
Answer:
Note: sftp is a "secure ftp" program. It works like a regular ftp client, but uses SSH to secure the traffic passing between the client and the server. As of version 3, WinSCP also supports sftp functionality.
I have a couple of niggling concerns with sftp:
sftp requires sftp-server on the server side. Some sites don't enable sftp-server, so it can be annoying to become overly dependant on sftp. All the functionality of sftp can be achieved with ssh/scp, without the need for new server-side programs.
sftp adds a new layer of protocol, which introduces new possibilities for security vulnerabilities.
My preference is to stick with tools that are implemented using the "basic" SSH protocols, but I accept the point that sftp would also get the job done, and may be easier to work with in many situations.
Question:
Subject: tunneling HTTP
Can I tunnel all my HTTP traffic through an SSH connection to a friend's Linux host?
Answer:
Tunneling only works from one host to another (single) host.
To tunnel all HTTP requests, you would need to establish tunnels between your machine and every other machine on the internet. Tunneling HTTP requests to a handful of webservers behind a firewall is feasible, but directly securing all HTTP traffic is not.
However, it is possible to tunnel HTTP requests indirectly:
You could install a HTTP proxy on the Linux machine, (such as squid, http://www.squid-cache.org/), then tunnel communications with the proxy, (port 3128 by default for squid). On the client machine, the HTTP proxy would appear to be running on localhost:3128. It would in fact be talking to squid on port 3128 on the Linux box.
This will secure traffic between your machine and the Linux box. However, the actual HTTP requests from squid to the rest of the Internet are not, (and cannot), be secured, (unless you somehow had SSH or SSL access to every other machine on the Internet). Given this fact, there's little to be gained from tunneling HTTP access through a proxy, unless you specifically want to encrypt the data between your machine and the proxy.