Freeware SSH and SCP for
Version 2.0 22 January 2001 |
|
|
 |
|
|
Contents |
If you're trying to access remote servers securely from Windows 9x, NT, NE, 2000 or XP and you don't want to pay money for programs that are freely available for UNIX and UNIX-like platforms, you may find this document useful.
"ssh" and "scp" are "secure" programs that work like "sh" and "cp" commands, (or rlogin and rcp, or telnet and ftp). They use public key cryptography to ensure secure transfer of data over insecure communication channels. (That would be your dial-up connection to "hackerz.inc" and suchlike.) "ssh" and "scp" are rapidly replacing "telnet" and "ftp" as the default means of communicating with remote servers.
Email me, fitz@jfitz.com, if you find better free implementations, or if you think there's anything I can add here.
Please note that this document is intended as a springboard to get you started with secure communications. There is a wealth of detailed information available through any major search engine. I have deliberately omitted links to other sites, (except for specific downloads), since information on this topic is constantly changing.
Also, please note that I will not include references to products that are not available free of charge. I also have a strong preference for open source implementations derived from a known code base. My belief is that something as fundamental as an SSH implementation should be included in all Operating Systems to begin with, so you shouldn't have to pay to add it. Also, I believe you should be aware of the version of code that an SSH implementation is derived from, so you can assess your exposure when new SSH vulnerabilities are discoved.
For more links to SSH tools for Windows, (and Mac), I'd recommend trying the OpenSSH Windows/Mac page: http://www.openssh.com/windows.html.
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 a bit 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 on the stored session name). This process is a little awkward, because you need to exit and restart PuTTY to update a stored session, but once you have one good set of settings saved, you can use that session like a template to create other stored sessions for different hosts.
(January 28 2002): I've created a step-by-step guide to configuring PuTTY, (including port forwarding), 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.
It's important to note that PuTTY works a lot 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 session settings can be changed.
To remove PuTTY, delete the files you downloaded. To clean up the registry, use regedit to remove the keys under HKEY_CURRENT_USER -> Software -> Simon Tatham -> PuTTY.
PuTTY and pscp support SSH versions 1 and 2, and an authentication agent is also available, (though I haven't used this myself).
The only downsides to PuTTY are that it does not include port forwarding, (covered later in this document), and it only allows you to copy text that is displayed on the screen.
Note (November 16 2001): The current development release of PuTTY, (which seems to be stable), includes port forwarding in the SSH options, (under the heading "Tunnels"), and it supports scrolling selection. With these additions, I'm inclined to favor PuTTY over Tera Term Pro for all my Windows ssh needs.
pscp is a pretty straightforward Windows implementation of scp. It is a command-line program only, so you need to run it in an MS-DOS window. Note: There is a windowed interface available, (in addition to the WinSCP implementation mentioned below), that I haven't tried myself -- see the PuTTY web site for details.
The basic format of a pscp command, (or an 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.
WinSCP provides a graphical "Explorer-like" interface to SCP functionality. It seems to be a fully featured SCP implementation, with an easy to use "front end", though I've not used it myself. You can find out more and download it here: http://winscp.vse.cz/eng/
WinSCP is open-source, though you may need to contact the author to get the latest code. It is partly based on PuTTY code, (version 0.51).
Another excellent terminal emulation package that supports SSH is Tera Term Pro. You can download it here: http://hp.vector.co.jp/authors/VA002416/teraterm.html
Again, this is pretty simple to install -- it comes with a regular Windows setup program. And again, 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 does not include SSH. For this, you need to download the ssh extension, TTSSH, which you can get here: http://www.zip.com.au/~roca/ttssh.html
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 (ttermpro.exe), and you should now have ssh available as an option during connect. Additionally, some SSH options are added to the Setup menu. You should change the defaults so that SSH, (on port 22), is the default connection method.
Tera Term Pro and TTSSH are larger and are slightly more difficult to set up, but they do overcome the limitations of PuTTY; namely, they support port forwarding and copying text from the scroll buffer.
Port Forwarding, (or "Tunnelling"), is a really neat mechanism for encrypting data transmissions that would not normally use encryption. Probably the most common use, (which is the example I'm going to use here), is to encrypt incoming and outgoing email from a remote mail server that uses POP3 and SMTP protocols.
For this to work, you will need an email account with a company, educational institute or ISP that has some clue about security, (certain ISPs could be a problem here). You must have an account on the mail server, (or a gateway to the mailserver), and an SSH server must be enabled on the mailserver/gateway. If these are not set up correctly, there's nothing you can do on your PC to make this work. You can bitch at your ISP, or just change to one that knows its business.
There are several free SSH implementations that support port forwarding. The latest development version of PuTTY, and Tera Tera Term Pro, (with TTSSH), include Port Forwarding in their SSH configurations options. Also, "Tunnelier" is a freeware tool, (not open source), specifically designed to enable Port Forwarding, (I haven't tried it myself).
In addition to the SSH package, you also need email client software that will support port forwarding. Most of the popular clients do, (Outlook Express, Netscape Messenger, etc. -- generally speaking, any email client that implements networking protocols correctly will support port forwarding, though I've encountered some less popular clients that don't work without some awkward DNS workarounds.)
Probably the easiest way to port forward is to save a session, (PuTTY or Tera Term Pro), that has the required ports forwarded, then create a shortcut that calls that session.
In addition, Tera Term Pro allows you to specify port forwarding with some additional parameters on the command line. I'll use the Tera Term command line as an example to illustrate what port forwarding does:
Create a shortcut to TTSSH.EXE on the desktop. Right-click on the shortcut, select "Properties" and then select the "Shortcut" tab. Now we add the required parameters to the "Target" field.
A typical target would look something like this:
"C:\Program Files\TTermPro\ttssh.exe" /ssh-L110:127.0.0.1:110
/ssh-L25:127.0.0.1:25 mail.myisp.net
(Note that all this would appear on the same line, with a space between the two "/ssh" commands.)
What this command is saying:
Connect to the machine mail.myisp.net using ssh. In addition, connect port 110, (POP3, incoming mail), and port 25, (SMTP, outgoing mail), on my local machine to the corresponding ports on mail.myisp.net, but send the actual traffic between these ports across the encrypted SSH link, (usually on port 22).
In general, 127.0.0.1 represents the address of the "local machine". It can usually be replaced with "localhost", (without the quotes), if you prefer this format. Note that in this case, 127.0.0.1 actually refers to mail.myisp.net, since the port forwarding instructions are passed to this machine. Depending on firewall configurations, you may also be able to substitute mail.myisp.net for 127.0.0.1.
Now, when we run this shortcut, and log on to our UNIX account, all traffic to/from our local POP3/SMTP ports is redirected over the encrypted channel to mail.myisp.net.
The only remaining task is to set up our email client so that it connects to the local POP3/SMTP ports instead of connecting directly to mail.myisp.net. You will need to check your email client documentation to see exactly where to set these parameters. For example, in Outlook Express, the information is under Tools -> Accounts -> Mail -> Properties -> Servers. Both POP3 and SMTP servers should be set to 127.0.0.1 or "localhost", (no quotes).
Note that in this case, I'm assuming that the remote mailserver and the machine with your UNIX account are the same machine. If there is a gateway or firewall machine at your ISP, the shortcut would look slightly different:
"C:\Program Files\TTermPro\ttssh.exe" /ssh-L110:mail.myisp.net:110
/ssh-L25:mail.myisp.net:25 gateway.myisp.net
This command tells "gateway.myisp.net" to forward traffic to/from the POP3/SMTP ports to "mail.myisp.net"
Both the command formats listed assume that POP3/SMTP are running on the standard ports; 110 and 25. You will need to change the port numbers as appropriate if this is not the case, (you will need to get the correct port numbers from your ISP).
Note (November 16 2001): The current development release of PuTTY includes port forwarding in the SSH options, (under the heading "Tunnels"). With this inclusion, I'm inclined to favor PuTTY over Tera Term Pro.
To add a tunnel in PuTTY, load a saved session that uses the SSH protocol, select the SSH Tunnel option, specify the port to forward in the "Source Port" field, then specify "hostname:port", (for example 127.0.0.1:110), in the "Destination" field and click "Add". Add other forwarded ports as necessary. Save the session. At this point, whenever that session is opened, the specified ports will be forwarded.
If you want to open a specific session without displaying the Configuration dialog every time, create a shortcut to PuTTY on the desktop, right-click the shortcut, select "Properties" and edit the "Target" field to include " @session-name". For example, if the "Target" field is "C:\utils\putty.exe", and you have a session saved as "MyISP" the new "Target" would be "C:\utils\putty.exe @MyISP". Running this shortcut instead of PuTTY will bypass the Configuration dialog, loading the "MyISP" settings.
(January 28 2002): I've created a step-by-step guide to configuring PuTTY, (including port forwarding), here: http://www.jfitz.com/tips/putty_config.html
Another excellent use for ssh port forwarding is to secure a VNC connection. VNC is a set of client/server tools that allow you to remotely operate a Windows or X-Windows workstation. VNC is freely available, and is arguably better than many commercial implementations. By default, VNC does not include a secure connection mode, but it does use predictable port assignments, so it's a good candidate for port forwarding. I find it so useful, I've put together a packaged Windows VNC client with a command line ssh program. The details are here: http://www.jfitz.com/vnc/
Note (November 16 2001): This section is still valid, but it's a little dated at this stage. Probably the best source for a command line ssh implementation for Windows is Cygwin, (http://www.cygwin.com/). Cygwin is a pretty complete GNU based, (i.e. UNIX-like), environment for Windows. In addition to the rich selection of GNU command-line programs, Cygwin also supports ports of XFree86 and KDE 1.1.2. While this is no substitute for a good Linux distro, it is handy for doing quick X Windows work on a UNIX server without needing to reboot your Windows box into Linux, or pay 100's of $'s for an X Server for Windows.
The best place to learn more about ssh/scp is on a *nix, (Linux, FreeBSD, UNIX), environment. It can also be useful to install command line versions of ssh and scp for Windows. These programs are small and therefore easy to keep on a floppy disk, and they can be included in batch files to automate secure operations.
You can download a win32 port of ssh/scp at one of the following sites, (Note: I'm not sure if ftp.cs.hut.fi still carries this stuff):
ftp://ftp.cs.hut.fi/pub/ssh/
ftp://ftp.net.ohio-state.edu/pub/security/ssh (USA Mirror)
ftp://ftp.gw.com/pub/unix/ssh (USA Mirror)
Download the following file from the "contrib" sub-directory:
07/26/97 12:00AM 116,798 ssh-1.2.14-win32bin.zip
(I haven't put a direct link to the download file, because you may want to check for more up-to-date ports.)
Unzip it in the following directory: C:\ssh\bin. (It doesn't have to go in C:\ssh\bin, but it'll keep the rest of the explanation simple.) There are five files. I'd recommend deleting SSH-KEYGEN.EXE - it doesn't work, and leaving it around only confuses things. This leaves SSH.EXE, SCP.EXE and two DLLs.
Change AUTOEXEC.BAT so that the BIN directory is in the PATH:
SET PATH=C:\SSH\BIN;%PATH%
Like its UNIX counterpart, the win32 port of ssh/scp looks for various configuration files in a "HOME" directory, and, (more importantly), in a subdirectory called ".ssh"
So, we also need to add a "HOME" directory in AUTOEXEC.BAT. For example:
SET HOME=C:\ssh
Create the HOME, (if you've followed my directory layout it's already there), and add the .ssh subdirectory:
MKDIR C:\ssh\.ssh
Like all good Windows installations, you need to reboot your machine for these changes to take effect. (Three cheers for Windows.) When these steps are complete, you should be able to run "ssh" or "scp" from a DOS window.
The "scp" command works pretty much like its UNIX counterpart, or pscp, with the following peculiarity: Both the local and remote file specifications must be in UNIX format, (use forward slashes "/", not back slashes "\", in directory specifications). This requirement means DOS drive specifications, ("C:"), cannot be included in the local file specification, so you can only copy to/from the current drive.
A more recent port of ssh/scp by Robert Bihlmeyer (robbe@orcus.priv.at) is available here: http://metternich.vibe.at/tools/ssh-w32/ssh-lose.html. I haven't tried this version myself, so I can't offer any opinions. Thanks to Gerald Pfeifer (pfeifer@dbai.tuwien.ac.at, http://www.dbai.tuwien.ac.at/~pfeifer/) for bringing this version to my attention.
One of the biggest problems with the command line scp under Windows is the fact that it doesn't support wildcard, (*.*), or recursive copying, (copying subdirectories). To get around this problem, I've written a small Windows utility that allows you to use DOS wildcards. It also includes a "-r" parameter to specify recursive copying. You can download the utility and its source code here: mscp1_0.zip (17K). The README.TXT file contains installation and usage information. Note that mscp simply calls scp and ssh for each file that matches the wildcard specification. If you have not specified an "authorized_keys" file on the UNIX side, you will be prompted for a password for each file that is transferred.
With any of the installations so far we can only use scp or ssh provided we supply a password each time. To be able to automate scp/ssh we need to generate secure keys. Remember I said that SSH-KEYGEN.EXE doesn't work? This means we have to log on to a UNIX box and run ssh-keygen from there.
(Note: We could probably still figure out a way to do this on the Windows machine, but the *nix ssh implementations tend to be more robust and up-to-date so this is my recommended approach.)
ssh-keygen should generate the following files in your .ssh directory on the UNIX machine:
"identity" is your private key. "identity.pub" is the public key. "random_seed" is, surprisingly, a random seed value.
Now use scp, (or pscp), to copy the keys to your PC. If you were to use ftp, you would have transmitted your private key over an insecure connection - this would not be good.
Do not scp the files directly to the C:\ssh\.ssh directory. This might confuse scp. Copy them to a holding directory. When you have them all, use DOS copy to place them in the C:\ssh\.ssh directory.
Note: Be sure to delete the key files, (especially the private key), from the UNIX machine once you have copied them to your Windows machine.
If you want to be able to ssh or scp to a trusted server without specifying a password all the time, add the contents of your public key, (identity.pub), to a file on the UNIX server called "authorized_keys" in the $HOME/.ssh directory of the user that you connect as.
Note: Make sure the "authorized_keys" file can only be read and written by the owner, (UNIX command to fix the permissions would be "chmod 600 authorized_keys"). Otherwise, it could be possible for others to add their public key to your authorized_keys file, giving them unrestricted access to your account.
Now, when scp or ssh attempts to connect, it passes "identity.pub" to the remote machine. The remote machine checks "authorized_keys", and if it finds a match, and the local machine can verify that it has the corresponding private key, it will allow the connection without password verification.
For this to work , you may need to check with your UNIX admin that ssh is configured to allow trusted access, and that the file and directory names are correct. Also, you must supply an empty "passphrase" when you are generating your keys, (otherwise you will just be prompted for the passphrase instead of your password).
You should only use this approach when absolutely necessary. It is reasonably secure, provided access to both machines is restricted. If someone manages to steal your private key, (probably not very difficult on most Windows machines), your UNIX account will be fully compromised.
If you want Tera Term Pro to allow secure login without passwords, select "Use RSA key to log in" from the login screen and set the "Private Key File" to be C:\ssh\.ssh\identity
(This shares your keys between Tera Term Pro and the command line ssh/scp so you only need to update a single key.) Note that you can update your keys whenever you wish using ssh-keygen. If you do, however, you will also need to update the "authorized_keys" files on any remote servers you may be accessing.
Similarly, you can use the same file for PuTTY, by setting the "Private Key File" option under the "SSH" option in the configuration screen.
The "known hosts" file is a list of hosts that you "trust" when using ssh or scp. All implementations of ssh/scp, (including PuTTY and TTSSH), will give warnings if you are connecting to a new machine that is not in the list of known hosts.
If you want Tera Term Pro to share its known hosts file with scp, (which is a good thing, since you get fewer warnings), go to the SSH option under Setup and change the known hosts file to C:\ssh\.ssh\known_hosts. If you've already used Tera Term Pro to create a list of known hosts, you may want to overwrite C:\ssh\.ssh\known_hosts with the contents of C:\"Program Files"\ttermpro\ssh_known_hosts, (this is TTSSH's default known hosts file).
PuTTY uses the registry instead of a file to store known hosts, so you will get separate warnings from PuTTY each time a new host is encountered.
The known host file holds the host name and the public key for that host. If the key is changed you may need to remove the old key from file, (or registry in the case of PuTTY), 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 with a different key.
This document was never intended to cover SSH server software for Windows, (and I don't think an SSH server for Windows is a great idea anyway), but I get so much email on the subject that I've decided to include this section as an introduction to the topic.
If you are interested, 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. Installing Cygwin is pretty straightforward, but configuring the SSH server may take a little work. Familiarity with a *nix Operating System would be a BIG plus, since most of the setup mimics *nix environments.
At the outset I said that I don't believe an SSH server on Windows is a particularly good idea, so you may be wondering what reasonable alternatives there are if, (for instance), you're trying to secure one or two Windows machines connected to the big bad Internet by a cable modem or DSL.
My personal approach was to invest the princely sum of $100 buying a cheap old PC, put one of the free *nix's on it, (I use FreeBSD), stick in two network cards, then setup a firewall, NAT, (Network Address Translation), ssh and a few other "goodies". The result is that I don't have to bother too much about trying to "force" UNIX software onto a "leaky" NT/Windows environment.
Using NAT, IPSEC, (Virtual Private Networking software), and/or ssh port forwarding I can access NT and Windows machines pretty much as if I was accessing them directly, (subject to the restrictions I choose to put on them), yet without compromising security, since the FreeBSD firewall is "policing" all traffic. (Note that I'm not suggesting that FreeBSD, or any other *nix, doesn't have security flaws, but I do think they're way ahead of a standard NT 4.0 server.)
To give you some idea of the kind of box that's required, I find a 166MHz pentium, with a 1G hard drive and 32M of RAM has plenty of horsepower to firewall a 100Mb fast-ethernet LAN with several machines behind it. It would even be sufficient to run a lightweight Intrusion Detection System, (IDS), such as Snort, (http://www.snort.org), which will give you additional information about attempted attacks. I've actually run quite happily with a bare-bones kernel on a 133MHz machine with 16M RAM, and with a web server running on the same box. Many posts I've come across on mailing lists swear by old 486's. This class of PC can be picked up in online auctions for $100 or less, including tax, shipping and network cards. A hub and a few cables might set you back another $30-40.
Bigger systems can be firewalled by adding more firewall machines. At $100 a pop, I would expect a lot of us could afford to buy a firewall machine for each individual Windows box if necessary.
It can be a lot of effort to get this set up initially, but its a VERY liberating experience once you master it.