Some of my colleagues are severly OS-impaired (i.e. they run some variant of MS-Windows). They live in the world of telnet and ftp. Unfortunately, this world is inherently insecure, the preferred secure alternatives being ssh and scp. Unfortunately, these are not trivial to setup on a Windows machine. The following collection of binaries and advice attempts to ease this process.
First download and run this package, extracting to a convenient location. I will use \ssh in my explanation, so put the stuff there, or adapt the descriptions as appropriate.
The next step installs a Unix-like home-directory. In a command shell, do
mkdir \homeSSH will store some information there, in a subdirectory named .ssh. As usual, you can give the directory a different name, just remember to change occurances of \home, later on.
You will also have to set up a "password file". This is done by creating a directory \etc, and putting the necessary info into \etc\passwd. For example, do:
mkdir \etc echo username:x:500:100:x:\home:x > \etc\passwdYou can replace username with your preferred account name. SSH will use this as a default to log you onto remote hosts. \home is, of course, your home directory location; the fields with x are not used by ssh.
There is one final thing to do, before you can use SSH. In a command shell, enter the following incantation:
set CYGWIN=ttyEverything should be in order now, try to connect to some host with something like
ssh username@somehostYou must replace somehost with the host you want to connect to, and username with the account name that this host's admin gave you. If you wrote the same name into your passwd file one step earlier, you can leave out the username@ part - ssh will default to that.
Just remember that the CYGWIN setting must be repeated when you open a new shell window. Writing a batch file is probably in order.
Once SSH is set up properly, you can use SCP right away. The only issue of note is that SCP does not always find SSH. Either put SSH into a directory contained in your PATH (which is advisable anyway), or pass the path to SSH in a parameter. E.g.
scp -S /ssh/ssh local_file username@somehost:remote_file-S takes a Unix-style path (forward slashes instead of backslashes). Your path is probably different, if you extracted SSH into a different directory.
Keys are generated and put to use just like under other platforms, so if you have done that before, you can safely skip this section.
Still here? Ok, let me tell you that apart from authentication with your password, you can also use a assymmetrical key scheme. "Assymmetric" means that these keys come in two parts, private and public.
Generating a key for use with SSH is easy, just start ssh-keygen. This will spend some time computing a random key for you. You will be prompted for a save location (the default is usually ok), and a passphrase. This passphrase is like a password (the usual rules apply), with the difference that it can be quite long (more than 100 characters, if you want). Longer passphrases are potentially more secure.
The main advantage of RSA keys is that one key may unlock a number of hosts. To make a key eligable for login to a certain host, you will have to authorize it. First, check where the public part of your key resides - it should be in a file ending with .pub in your \home\.ssh directory. It is completly safe to pass this public part around (that's why it is called public), one can't guess the private part by knowing only the public part. By the way, the private part is stored in a file with the same name, only without the .pub suffix.
Transfer the public part of your key to the host you want to access with it. E.g. do
scp /home/.ssh/identity.pub username@somehost:Then, on the remote host, add the public part to the list of authorized keys (which usually resides in .ssh/authorized_keys under your home directory). Now you are set. The next attempt to log into this host should ask you for your key's passphrase.
When using RSA keys a lot, ssh-agent comes in handy. With it, you have to enter your passphrase only once, not on every use of your key. The agent will hold your private key (which the passphrase unlocks) in memory, and hand it out to SSH processes that need it.
But I have not succeeded in making the agent work under Windows. The Windows security model being what it is, I don't know whether this is really a bad thing. Anyway, perhaps this will work some time in the future ...
All binaries are based on the Cygwin environment. My SSH package consists of cygwin1.dll (local copy) and the binaries built by me with Cygwin beta 20 (local copy). The SSH source code is taken from the ssh 1.2.26 distribution (local copy), with diffs by Sergey Okhapkin (local copy) and my own diffs applied.
I guarantee with my signature that I did use exactly the abovementioned components, as available on 1998-04-23, assembled them in good faith, and with my best effort.
I CAN NOT, however, guarantee that the resulting package transfers your data securily, or even that it does anything useful. There are NO WARRANTIES OF ANY KIND. If it breaks, you can keep the parts.