NOTE: The following is my understanding of current laws and regulations, based on my reading of popular journals which I believe to be reputable. However, this is not legal advice - if you want legal advice, you should contact a lawyer. Unfortunately.
It is probably illegal to export SSH out of the United States. There is a regulation called the International Traffic in Arms Regulations (ITAR), and encryption software is considered an armament. ITAR prohibits the export of strong encruption software. However, the 1st amendment grants you the right to publish most anything, and given the widespread availability of strong encryption software elsewhere, it seems to me that there is no compelling national security argument to suspend your first amendment rights.
It is perfectly legal to import SSH into the United States.
It is legal to export Windows/NT from the United States. Windows/NT contains strong encryption software - or does it merely purport to? Nobody really knows for sure.
It is probably illegal to import, use or even posess SSH in France. Go figure.
Most other countries in the world have no special treatment of encryption software. Burma, I am told, makes it illegal to possess a modem.
Open source software developed outside the United States can resolve most of these problems (except the French and the Burmese).
In any cryptosystem, a message (the "cleartext")
is converted to a number or a string of numbers, encrypted (the "cyphertext"),
transmitted, decrypted, and converted back into the message. This
is represented symbolically as
C = E(M)
M = D(C)
Where M is the cleartext message, E() is the
encryption function, C is the cyphertext, D() is the decryption function.
In a public key cryptosystem, this process is
only slightly different. There are 2 keys Ku and
Kr
, the public key and the private key. In the
most general public key cryptosystems,
C = E(M, Ku)
M = D(C, Kr
)
This means that you encrypt a message with a public key and decrypt
a message with a private key. Thus, only the intended recipient can
get the message. However, most public key cryptosystems use the same
function F() for encryption and decryption:
C = F(M, Ku)
M = F(C, Kr
)
Which is the germ of how SSH works. As described so far, anybody
can create a cyphertext that only the intended can receive. However,
we can extend this system to create a cyphertext that only the intended
can receive, and that only the named sender could send. Suppose Alice
has keys Ka,u and Ka,r and
Bob has keys Kb,u and Kb,r
If Alice wants to send a message to Bob, the
message is handled as
C = F(F(M, Kb,u),Ka,r
)
M = F(F(C, Kb,r
),Ka,u
)
Note that Alice uses her private key and Bob's
public key. Bob uses his private key and Alice's public key.
The only problem now is to find some function F that will do all this.
The important point of this section is that you may freely distribute the
public keys, but you must not distribute the private keys.
| platform | 1.2.x | 2.x | |
|---|---|---|---|
| UNIX | ftp://ftp.cs.hut.fi/pub/ssh/ | ||
| Windows | ftp://ftp.netsoc.ucd.ie/pub/computing/ssh/ssh3298274.zip
http://www.doc.ic.ac.uk/~ci2/ssh/ssh3299054.zip (client) |
||
| Macintosh |
In an ideal world, there would be a public key server, a system where anybody could go an get your public key. Absent such a system, you have to distribute your public key by hand.
In an ideal world, I ought to be able to explain every field in this
box.
ssh remote_machine
Here is an example of failed scp session:
[jeffs@indiana ~]$ scp orange:Diamond5.java .
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? y
Are you sure you want to continue connecting (yes/no)? yes
Host 'orange' added to the list of known hosts.
Creating random seed file ~/.ssh/random_seed. This may take
a while.
Permission denied.
[jeffs@indiana ~]$
This failed because I haven't established indiana as a known machine to orange. To allow access to a system for a given identity place the public key in your ~/.ssh/authorized_keys file on that system. All keys listed in that file are allowed access.
Usually you will want to authorize access to the local system using the local key (especially in an environment where multiple systems share the same home directory e.g. using NFS). Thus a good start is to copy the public key for your default identity into the ~/.ssh/authorized_keys file.
orange% cd ~/.ssh
orange% cp identity.pub authorized_keys
You could now copy the ~/.ssh/authorized_keys file to other
systems to allow access from the local system. One way to copy the file
is to use the ftp command. Another way is to cut and paste text from
X-window to X-window, but remember that each key is exactly one line!
You can also mail the file.
Use a text editor to add more keys to the file. If you use cut and
paste to copy the key make sure each key entry is a single line in the
file. The keys to add are always the public keys (from files with the .pub
extension).
NOTE: To gain access to restricted systems you might need to send your public key in electronic mail to the administrator of the system. Just include the contents of the ~/.ssh/identity.pub file in the message.
So I copied the contents of my indiana.pub file into the known_hosts file. Then, my known_hosts file looks like this:
web 1024 37 15610762896617817257559300934701134297912920019988780620613645880597572411113362754109212107179767919846936889348695084201076593562581906321959081593207456034098779287748876740248902473684871488071131223508392402361318102953561793474267261560318767764052503474713799031566629794674788812757153717127218897
web.statsci.com 1024 37 1561076289661781725755930093470113429791292001998878062061364588059757241111336275410921210717976791984693688934869508420107659356258190
21959081593473207456034098779287748876740248902473684871488071131223508392402361318102953546179347426726156031876776405250347471379903156662979467478881275715
3717127218897
indiana.statsci.com 1024 35 115370462496949242165304748913199410741511660101831672851838580829655204342055588506005535765947845721032355355349925147493069333519
031626368285777607515148183860680961947200206518786836750365874565054084626232059028770520751800335882217341981473558431434226791880321128535721491945107519889
12026930590458943
(The file really is 3 lines long, but the browser probably has troubles rendering lines 300-400 characters long).
Now that I have made indiana known to orange, I can try the copy operation
again:
[jeffs@indiana ~/.ssh]$ scp orange:Diamond5.java .
Enter passphrase for RSA key 'jeffs@indiana':
before running the common.cshrc, path is /bin /usr/bin /usr/ucb
/usr/bin/X11 /usr/local/bin /sw/.mtype/bin
[jeffs@indiana ~/.ssh]$ Write failed flushing stdout buffer.
write stdout: Broken pipe
[jeffs@indiana ~/.ssh]$
Again, it fails, but this time for a different reason: there is output on stdout from the .cshrc file which is polluting the connection process (output on stderr is not a problem)
[jeffs@indiana ~/.ssh]$ scp orange:Diamond5.java .
Enter passphrase for RSA key 'jeffs@indiana':
stty: : Invalid argument
term: Undefined variable.
Diamond5.java
| 1 KB |
1.6 kB/s | ETA: 00:00:00 | 100%
[jeffs@indiana ~/.ssh]$
Another example, this time, copying the file WebSpider2.java on orange to my local machine directory hacks/JavaSpider
[jeffs@angel jeff]$ scp orange.statsci.com:WebSpider/WebSpider2.java
hacks/JavaSpider
Enter passphrase for RSA key 'jeffs@angel': pass phrase here
stty: : Invalid argument
term: Undefined variable.
WebSpider2.java
| 4 KB |
4.7 kB/s | ETA: 00:00:00 | 100%
[jeffs@angel jeff]$
Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do
myhost$ ssh -L 1234:ftphost.do.main:21 ftphost
This logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost.
Then, in another window, you do
myhost$ ftp mymachine 1234
220 ftphost FTP server (Foonix 08/15) ready.
Name: (myhost:yourname):
331 Password required for yourname
Password:
230 User yourname logged in.
This works if the remote ftp daemon accepts PORT commands which specify a different host from the one the command channel appears to come from, and if the ftp client always uses PORT. This is true for vanilla UNIX ftp client and ftpd servers; it may not work for more advanced ftpds, such as wu-ftpd.
For servers which do not accept this, you can see wether you ftp client supports passive mode, and whether the ftp server accepts PASV.
For POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) has written a script which protects the mail transfer and passwords ussing ssh. It requires no modification to existing POP servers or clients, and is available from ftp://ftp.pasteur.fr/pub/Network/gwpop/ .
Other services could be secured by similar means. Note, however, that
unencrypted ftp data connections are still vulnerable to session hijacking
and snooping.
The Irish Linux Users Group has a terrific
page on ssh. A lot of the prose I pilfered from there.
There is a quick
start article at the U. of Minnesota.
The official SSH FAQ (Frequently Asked Questions) is from Germany.
Jim Tollefson recomends this
article for startup information on ssh.
The ssh man pages are on indiana but not on orange. I don't know
why.
The SSH Home Page has information
on the protocol and distribution of ssh.
psst... has information
about free implementations of the ssh protocol (from the United Kingdom)
TTSSH is a free ssh client for Windows. It is an extension for TeraTerm
Pro.
NiftyTelnet
SSH is a free ssh client for MacOS. It is an enhanced version of NiftyTelnet
(From Sweden)
Data Fellows offers commercial
implementations of ssh (This is an Finnish company. Note the proximity
of Finland to Russia. Recall how Finland was invaded by Russia in
World War II. You remember WWII - it was in all the papers.
The Finns have no problem with the development of strong cryptography -
maybe they know something).
SSH Communications Security has information
about the development of ssh (This is also a Finnish company).
Links2Go SSH Topic
lists most commonly cited pages for ssh.
See the NPACI security page for details.