|
|
The secure shell (ssh) creates a very secure connection when you need to move data or yourself from one machine to another over the network. It is the only allowable way to connect to OGI Unix or Solaris servers.
The simplest way to use ssh is to invoke it as follows:
login% ssh remote.host
(where remote.host is the name of the computer to which you'd like to connect). You'll be prompted to provide your password. If the login is successful, you'll be given a command prompt.
The difference is that all the communication between your computer and the remote machine are encrypted. Nothing is passed in plain text that can be easily spotted by a sniffer.
By default, ssh assumes that your local username and remote username are the same. If your remote user name is different, then you can use the -l switch (that's a lower-case L, not the numeral one):
login% ssh -l remotename remote.host
or as a variation:
login% ssh remotename@remote.host
One cool thing about ssh is that it keeps track of the remote machines you've visited in a file called ~/.ssh/known_hosts. Whenever you visit a new machine, ssh will ask you if you want to add that machine's public key to your known_hosts file. Every time you visit that machine, ssh will check to see if it still has the same key. If not, you'll get a loud message like:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
If you know that the remote server has not changed its key, then someone is doing something nasty and you can refuse the connection.
ssh will automatically set up your Unix environment variables, so you don't have to go setenv-ing or export-ing them to run X apps remotely. Try this:
% ssh -f login xterm
Voila! Instant remote xterm. Or, if you'd like to do some remote text editing,
% ssh -f login emacs
The -f switch requests ssh to go to background after authentication is done and forwardings have been established.
One of ssh's strengths is that it allows you to do "port forwarding," which is a great mechanism for encrypting, say, e-mail downloads.
When you start up your e-mail client and connect to the remote server, you're asked to provide a username and password. Your e-mail program then sends that information over the Internet in the clear, with absolutely no protection against folks who might be "sniffing" Internet traffic.
One possible (though decidedly convoluted) way to secure your email sessions is with ssh port forwarding. This way ssh will encrypt these transmissions, so your password stays private. (Note: The following examples assume that you already have ssh running on your home machine.)
IMAP Forwarding
To encrypt IMAP sessions to the CSEE mail server, execute from the command line
% ssh -L 9000:localhost:143 mailhost.csee.ogi.edu
Here's what we've done:
ssh ... mailhost.csee.ogi.edu opens a secure shell session to mailhost.csee.ogi.edu
The -L option turns on port forwarding
9000:localhost:143 means that ssh will open a socket on port 9000 on your local machine, and all traffic to it will be forwarded to port 143 (the IMAP port) on localhost, which in this case is mailhost.csee.ogi.edu.
(Yeah, this is confusing -- but the localhost part of the command is relative to the remote machine (mailhost), not your local machine).
I've used port 9000 in this example, but it can be any unused port above 1024; 9000 is a good potential starting point.
Now, open your IMAP mail client (Outlook, Thunderbird, Pine, etc) and point it to localhost (which is your machine), port 9000. ssh will transparently route -- and encrypt -- your mail traffic.
POP Forwarding
To encrypt POP sessions to the CSEE mail server, execute from the command line
% ssh -L 9000:localhost:110 mailhost.csee.ogi.edu
Open your POP mail client (Outlook, Thunderbird, VM in Emacs, etc) and point it toward localhost port 9000. Voila!
You're not limited to tunneling just one port per session. Take this command, for example:
% ssh \
-L 9000:mailhost:143 \
-L 9001:nntphost:119 \
mailhost.csee.ogi.edu
This would provide
direct encrypted communication with the CSEE IMAP server, via port 9000 on your local machine
encrypted communication between you and mailhost and then unencrypted (but pretty secure, switched LAN) communication between mailhost and nntphost, the CSEE news server, via port 9001 on your local machine
OHSU :: OGI :: CSEE :: Support :: CSEE :: Unix
This page was most recently revised on February 03, 2006.
Please address questions or comments to the webmaster.