|
The Great SSH Primer for the Chemistry Department
|
Last update:
Tue Dec 13, 2005
Contents:
The practical part
The more theoretical part
The practical part
- A Slide Presentation
Click here to view a
presentation on SSH, given to the Chemistry Department on December 13, 1999.
- What is SSH?
SSH (Secure Shell) is a program to log into another computer over a network,
to execute commands in a remote machine, and to move files from one machine
to another. It provides strong authentication and secure communications over
insecure channels. It is intended as a replacement for telnet, rlogin, rsh,
rcp, and rdist.
In addition, ssh provides secure X11 connections and secure forwarding of
arbitrary TCP connections (such as pop, imap, smtp, http).
- When will I need SSH in the Chemistry Department?
You need SSH under the following circumstances:
- You used to telnet into the chemistry Unix server
(chemistry.ohio-state.edu) from outside the Department (you will now need
SSH as a replacement for telnet, rlogin, rsh)
- You used to read your email with a POP or IMAP based mail program that
does not support secure access via SSL (example: versions of Eudora before
5.1) from outside the Department (you now use the SSH
tunelling feature that allows you to forward TCP connections through an
encrypted tunnel).
Note: If all you want to do is access your email from outside the Department,
you may not need SSH; see the FAQ How can I
access my email from outside the Department? for more information.
- You used to ftp into the Department (you can now tunnel part of the
FTP communication through an SSH tunnel, or you can use SFTP).
- You used other departmental resources from outside the Department that
required you to send your username and password across the net in the
clear
- You need to use X11 between computers inside and outside the Department
(you can now use the X11 tunneling feature).
- You need to relay email through the chemistry Unix server from outside
the Department with an email client that doesn't support encryption and
authentication (see email
relaying FAQ)
Exception: You will not need SSH if you do all the above from Homenet.
- Legal aspects of strong encryption
Strong encryption, as employed by SSH and other security products, is still
classified as a munition by the US Government. It
is illegal to export encryption software. The act of electronically or
otherwise transmitting or shipping software from the US to a destination
abroad, even if the software was written or purchased abroad, legally counts
as exporting the software and is thus prohibited by current US law. Violation
of export laws on encryption products is a felony.
If you own a laptop and have SSH installed, it is still possible to travel
abroad, as long as certain conditions are met. The following information was
provided to us by Steven J. McDonald, J.D., Associate Legal Counsel for the
University. It provides current information as of now (November 1999).
Note (3/2/01):
Encryption legislation is a moving target; things change constantly, and the
legal texts are difficult to understand (for a lawyer). Since November 1999,
there have been several changes in export restrictions (the restrictions have
been relaxed somewhat). If you adhere to the guidelines below, you should
therefore be ok.
SSH on laptops when travelling abroad (Local access only)
- What SSH clients are available for PCs and Macs?
- SecureCRT: http://www.vandyke.com
32bit version for Windows95/98/NT; no Mac version
Cost: $32 (this is an educational/volume price; the price listed on the web page for a single
copy is $99.99)
You can download a fully functional demo copy for a 30-day trial period.
Note (11/30/00):
The latest version of the SSH2 daemon on the chemistry Unix server
apparently does not respond properly to the SSH2 negotiation attempted by
SecureCRT with its default settings. Two solutions have been found. Switch
your protocol to SSH1, or switch your server type to "Standard" vs. the other
choices "Datafellows 2.0.12" or "Datafellows 2.0.13" or "SSH Communications
2.1.0 (beta)". This option may only be available in recent versions of the
SecureCRT's SSH product, available for download at www.vandyke.com, and
quickly installable.
- F-Secure: License and CDs can be purchased at Unicomp (OSU Bookstore Computer department)
(University site license)
Windows and Mac versions
Cost:
$25.99 new, with media
$18.99 new license, no media
$6.99 license upgrade, no media
For more details, see
http://www.osu.edu/units/uts/site_license/
To download demo copies, see
http://f-secure.com (look for F-Secure SSH client) and
click here for a local set of configuration intructions.
- SSH Secure Shell: excellent free SSH client, Windows only
Supports SFTP (secure FTP)
Can be downloaded from the
OIT Software Downloads site (go to "Software for Windows 9x/NT/2000" and look for SSH Secure Shell, V3.x)
- TeraTerm: Teraterm Pro is a superb free terminal emulator/telnet client
for Windows, and its source is available. TTSSH is a free SSH client for
Windows. It is implemented as an extension DLL for Teraterm Pro. TTSSH adds
SSH capabilities to Teraterm Pro without sacrificing any of Teraterm's
existing functionality. TTSSH is also free to download and use and its source
is available too, with an open source license.
Both Terraterm and the ssh add-on can be downloaded from the TTSSH Home
Page:
http://www.zip.com.au/~roca/ttssh.html
- PuTTY: another free SSH client for Windows; includes an xterm emulator
Can be downloaded from
http://www.chiark.greenend.org.uk/~sgtatham/putty/
- NiftyTelnet with SSH: This is an enhanced version of NiftyTelnet, a popular terminal emulator
for Macs, with SSH support
Does not have the capability to establish an SSH tunnel to do port forwarding
Can be downloaded from
http://www.lysator.liu.se/~jonasw/freeware/niftyssh/
- MacSSH/MacSFTP: Macintosh "classic" and OSX versions of this client available.
Supports tunneling/port forwarding.
Based on OpenSSH. Current version 1.0.5 (as of October 2002). Shareware (15-day free trial
before requiring a serial number, then $25 for single user license).
Can be downloaded from
http://www.macssh.com
We have installation instructions for MacSSH on PowerPC CPUs in this
FAQ.
- Gideon (for Mac OSX only): FTP/SFTP client. Note: Current version
1.0a4 (as of October 2002) NOT compatible with OSX 10.2 (Jaguar) -- new release in
development, but is compatible thru 10.1.x. Shareware;
author requests $25 for
single user license. Nicer interface than MacSFTP; also includes
powerful filtering features and capability of viewing/editing files
on remote machine.
Can be downloaded from
http://www.gideonsoftworks.com/gideon.html
- Fetch Softworks, maker of Fetch (the
well-known FTP client for Macs, with current versions available for
classic and Mac OSX), is supposedly developing a version of Fetch that
will support SFTP. No info is currently available on a possible
release date (as of October 2002).
Can be downloaded from
http://fetchsoftworks.com
- Built-in SSH/SFTP (for Mac OSX only): SSH and SFTP are available on the Mac OSX command line;
for an example how to use SFTP, see the FAQ
SFTP from the command line in MacOSX
- Fugu (for Mac OSX only): Graphical wrapper for the command line
MacOSX SFTP client. Includes drag and drop uploads and downloads, directory
uploads (not natively supported in SFTP), directory download via SCP, point-and-click
permissions, owner and group modification, SSH Tunnel creation.
Can be downloaded from
OIT Software Downloads site (go
to "Software for Macintosh" and look for Fugu)
- Mindterm: a Java based client that runs on any operating system with a JavaVM environment, including
Macintosh and Windows
Can be downloaded from
http://www.mindbright.se/mindterm/
This client is available as a downloadable applet from from the Computer Support web pages; go to
Internal --> Computing --> SSH to chemistry Unix server
If you're on the road, or if you don't have any of the other SSH clients
installed on your PC, Mac or Laptop, you can use this applet to SSH to the
chemistry Unix server.
A nice list of commercial and free clients is available at
http://www.cs.hmc.edu/tech_docs/qref/ssh.html.
Note (September 10, 2000):
The reason why there have been no free legal SSH clients for Macs until now
is that the existing ones have all been based on version 1 protocol of SSH
(see below), which in turn relies on the RSA encryption
libraries that were patented and thus illegal to run in the US. The RSA
patent would have expired on September 20, 2000 (after 17 years). RSA Data
Security Inc., the holder of the patent, put the RSA public-key encryption
algorithm into the public domain on September 6, 2000, two weeks before the
natural expiration of the patent. This means that United States users can now
download and use these free SSH clients legally.
- What are SSH tunneling and port forwarding, and how do
I set them up?
- How do I define port forwarding?
When you establish an SSH connection, what you get is a secure telnet-like
terminal emulator window. Through this secure connection you can piggy-back
other traffic (communication protocols). This is the SSH tunnel. Think of it
as a fat pipe between your client and the server host that is created when
you establish the SSH connection. Through this fat pipe you can tunnel other
protocols. Each protocol uses what's called a "port". For example, if you
send email, you use the SMTP protocol (Simple Mail Transfer Protocol), and it
uses the SMTP port. If you forward a port through your secure SSH tunnel,
then you do port forwarding.
While you cannot connect to the chemistry Unix server anymore using certain
protocols that transmit usernames and passwords in the clear (such as POP,
IMAP, TELNET), you can tunnel these protocols through your SSH tunnel and
continue to use mail programs such as (old versions of) Eudora that use POP
or IMAP and that don't support SSL (secure sockets layer) encryption.
The details of how you set up port forwarding depend on the SSH client you
use. When you are about to open an SSH connection, look for buttons such as
"Properties", "Edit --> Settings", "Advanced" configuration items,
"Tunneling" and/or "Port Forwarding".
Example:
SSH Secure Shell Client (the one from OIT's Software To Go server):
Double-click on the program icon --> Edit --> Tunneling --> Outgoing -->
Add.
Note: Click here to learn about how to
configure port forwarding in F-Secure. F-Secure is different and more
complicated to set up than most other clients and thus warrants a special
FAQ.
The ports you need to forward for mail programs such as Eudora to work are
the following:
- if the configuration menu distinguishes between "local" and "remote" ports,
you need to forward "local" ports
- if there is a check box "Allow local connections only", make sure it is checked
(otherwise anybody on the Internet can connect through your computer and through
your SSH tunnel! That would be a very bad thing indeed)
- if the configuration menu distinguishes betwwen "outgoing" and "incoming" tunnels,
you need "outgoing" tunnels
- "remote hostname" is the same as "destination host"
- "listen port" is the same as "local port"; "destination port
is the same as "remote port"
- for all "remote hostnames" enter "chemistry.ohio-state.edu"
- forward SMTP, local port number 25, same remote port number
- forward POP, local port number 110, same remote port number
- forward IMAP, local port number 143, same remote port number
When you are done, your configuration should look something like this:
- How do I tell Eudora to use the forwarded ports?
You can then reconfigure your mail program (e.g. Eudora):
- SMTP server: localhost (instead of chemistry.ohio-state.edu)
- POP server: localhost (instead of chemistry.ohio-state.edu)
So you redirect sending and receiving of email to the local endpoint of your
encrypted tunnel created by your SSH connection. With this configuration,
you can even relay email through chemistry from outside the University with
an email client that doesn't support encryption and authentication (see
FAQ "Why can I not relay email
anymore? - Solution 2"), because the other end of the SSH tunnel is on chemistry,
and the traffic that you send through the tunnel appears as local traffic
on the chemistry Unix server.
- What other ports can I forward?
You can forward other ports as well, such as HTTP (port 80):
Whenever you go to URL "localhost" in your web browser, you will see the
Chemistry Home Page (but your traffic is encrypted, in case you fill out web
forms that require sensitive information, and your connections appears to
originate from within the Department, so you have access to some of our web
pages that are only viewable from within the Department). Or you can tunnel
TELNET (port 23) as in the following example:
On your client computer, whenever you telnet to "localhost:12345" you will then
actually go through the encrypted tunnel to chemistry and then transparently
telnet from chemistry to the regular telnet port 23 on host "myhost" elsewhere
in the Department. This is convenient if you want to login on a Unix computer
in your research group in a one-step process.
Note: Whenever you want to do port forwarding as
in any of the above examples, you first have to ssh to the chemistry Unix
server and leave your SSH connection open in order for the port forwarding to
remain active.
Security Note: Some older SSH clients may by
default allow other computers to connect to your forwarded ports. This would
completely bypass all our firewall blocks (since such traffic would go
through your SSH tunnel) and allow a hacker to use your already authenticated
session to the chemistry Unix server to do whatever he/she wanted. If you
find such options for your SSH client, make sure only local applications can connect to your computer's
ports.
- What is X11 packet forwarding, and how do I set it up?
Most SSH clients support forwarding of X11 packets. There should be a check
box under "Port Forwarding" in the "Advanced" configuration settings, or under
"Tunneling", depending on the client.
If you run an X-server on your computer (such as eXceed on a PC, or MacX on a
Mac), you can then tunnel X11 applications through your SSH tunnel between
the chemistry Unix server and your local computer. Your DISPLAY on chemistry
should automatically be set to point to the SSH tunnel as soon as you ssh to
chemistry, and you can start any X-application.
Example:
> echo $DISPLAY
chemistry.ohio-state.edu:18.0
> xclock &
The xclock application will come up on your computer.
In general, X-applications require a lot of network bandwith. If you want to
do this from home, you will only get reasonable performance if you have a
broadband connection to the Internet (such as Roadrunner).
Security Note: You should set up the security of
your X-server such that only "localhost" is allowed to access your computer.
You should NEVER allow arbitrary hosts to access
your X-server (if you do, any hacker can read your keystrokes, insert
keystrokes and hijack your X-applications!).
Access to your X-server from the other end of the SSH tunnel (i.e. from the
chemistry Unix server) is controlled through entries in your .Xauthority file
in your home directory. Only someone in posession of your .Xauthority file
can access X11 forwarding through your SSH tunnel.
If you want to run an X-application on a Unix computer other than the
chemistry server, for example on mendelevium or any other machine in the
Department that mounts the central /home filesystem on chemistry, simply set
your DISPLAY environment variable to the setting that you got on chemistry and
run your application as before.
Example:
> echo $DISPLAY
chemistry.ohio-state.edu:18.0
> rlogin mendelevium
> echo $DISPLAY
DISPLAY: Undefined variable.
> setenv DISPLAY chemistry.ohio-state.edu:18.0
> echo $DISPLAY
chemistry.ohio-state.edu:18.0
> xclock &
If you want to run an X-application on a Unix computer that is not integrated
into the central cluster, i.e. on a computer that does not mount the central
/home filesystem, you first need to copy the file .Xauthority from your home
directory on chemistry to your other Unix computer and then proceed as in the
above example.
- What are SSH version 1 and version 2 protocol?
These are two completely different implementations of SSH. Version 1 is
widely available, version 2 includes more features and is slowly becoming
more wide spread. Some SSH clients support either version 1 or version 2
protocol, but not both.
The chemistry Unix server supports both versions. Other sites may not. If you
want to buy an SSH client that you can use with servers other than chemistry,
you may at this point (March 2000) want to buy a version 1 client (or one
that supports both versions).
- Where does FTP fit into the SSH scheme, and how can I
tunnel FTP?
FTP does not fit very well into this scheme. It uses two ports, a command and
a data port and does not lend itself to transparent tunneling
through your SSH tunnel, at least not for both ports.
There is an application called SFTP (secure FTP). If you can get it, or if
your SSH client includes it, use it; the chemistry Unix server will support
it. It uses version 2 protocol. There is no SFTP using version 1 protocol.
SFTP is supported in SSH Secure Shell, V2.x, the free SSH client for Windows
that is available from the OIT Software to Go server.
If you don't have SFTP, you can at least tunnel the command-port of FTP
through your SSH tunnel. This will protect your username and password (the
command port includes everything that you type while running FTP), but not
encrypt the data files that you transfer (those go through the data port).
Unless you transfer sensitive files, this is often all you need.
Remember: Click here to see how to set up port forwarding.
You have to set up the following port forwarding:
Port 21 is the command channel port of FTP. If you use Netscape
to FTP, you can type the following URL into your browser (example:
your username is "juser", and your home directory on the chemistry Unix
server is /home/graduate_students/juser):
ftp://juser@localhost/home/graduate_students/juser
When you are prompted for a password, supply your chemistry Unix password.
To transfer files from your computer to your Unix account, simply drag the file(s) into the
Netscape window. You will be prompted "Do you want to upload the dragged files to the FTP server?";
respond 'OK'. To view a file on the Unix server, simply click on it. To download a file, hold the
shift key down as you click on it.
Note: According to our tests, this works fine with Netscape,
but it doesn't appear to work with some versions of Internet Explorer!
To FTP to a host other than the chemistry Unix server, create another tunnel
like this (note that the local port number "23456" is arbitrary; it can be any
port that does not interfere with other tunneled ports):
The computer MYHOST could be any Unix or Windows machine in the
Chemistry Department that runs an FTP server.
You can type the following URL into your Netscape browser (example: your
username on MYHOST is "username", and your target directory on MYHOST is
"directory"):
ftp://username@localhost:23456/directory
When you are prompted for a password, supply your password on MYHOST.
To use an FTP program such as WS-FTP95 LE, you would configure it
in the following way:
+---------------------------------------------------------------+
| __________ |
| |General| |Startup| |Advanced| |Firewall| |
|-----------------------------------| |------------------|
| |
| Connection Retry [0 ] |
| |
| Network Timeout [65 ] |
| |
| Remote Port [2345 ] <----- This is important |
| (default: 21) |
| |
| [X] Passive transfers <----- This is important |
| |
| |
| |
| |
| |
| |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| _________ |
| |General| |Startup| |Advanced| |Firewall| |
|-| |-----------------------------------------------------|
| |
| Profile Name: [ SSH-Chemistry ] |
| |
| HostName/Address: [ localhost ] <--- also important|
| |
| Host Type: [ Sun Solaris ] |
| |
| User ID: [ juser ] [ ] Anonymous |
| |
| Password: [ ******** ] [X] Save Pwd |
| |
| Account: [ ] |
| |
| Comment: [ Through SSH to Chemistry ] |
| |
+---------------------------------------------------------------+
The more theoretical part
- Credits and Sources
Parts of the following discussion were taken from the README files that come
with the SSH source code distribution. Some other parts were taken from an
SSH FAQ at
http://www.uni-karlsruhe.de/~ig25/ssh-faq/index.html (this FAQ is aimed
more at installers of SSH than end-users).
The official SSH distribution site for the complete source code (from which
you can build SSH for Unix computers) is at
http://www.openssh.org.
- What are the features of SSH?
- Strong authentication.
- Improved privacy through strong encryption. All communications are
automatically and transparently encrypted. RSA encryption is used for key
exchange, and a conventional encryption algorithm (normally IDEA, Blowfish,
or triple-DES) for encrypting the session. Encryption is started before
authentication, and no passwords or other information is transmitted in the
clear. Encryption is also used to protect against spoofed packets (i.e.
packets which pretend to come from another, trusted host).
- Secure X11 (X-windows) sessions. The SSH program automatically sets the
DISPLAY variable on the remote machine and forwards any X11 connections over
the secure channel. X11 is used to display X-applications (such as xterm,
xclock, etc.) on PCs running eXceed, Macs running MacX, or Unix
workstations.
- Secure forwarding (tunneling) of arbitrary TCP connections. SSH creates a
"tunnel" through which protocols such as POP (Post Office Protocol) and IMAP
(Internet Mail Access Protocol), SMTP (Simple Mail Transfer Protocol) and
HTTP (Hyper Text Transfer Protocol) can be forwarded. The first 3 are used to
read, manipulate and send email from clients such as Eudora or Outlook
Express to a mail server.
- Never trusts the network.
- Automatically executes conventional telnet/rsh (after displaying a
warning) if the server machine is not running sshd, the SSH daemon process
(the program that decrypts your SSH session on the remote machine).
- What makes a communication channel secure?
When talking about secure communication, there are three main issues that need
to be considered:
- Secrecy - "nobody else can read it"
- Authenticity - "it comes from where it claims to come"
- Integrity - "nobody has tampered with it"
The first issue is taken care of by encryption; the data are
scrambled and cannot be read without the proper key (decryption key). The
second and third issues are taken care of by authentication; the
message is "signed" by adding extra data (the signature) to the message that
is a function of the content of the message, as well as a function of some
shared secret. Authentication can also be based on a trusted third party. Both
encryption and authetication rely on encryption algorithms.
Many encryption algorithms were developed in the 1970s. There are two classes
of algorithms:
- symmetric algorithms (example: DES, the Data Encryption Standard)
- asymmetric or public key algorithms (example: RSA, named after Rivest,
Shamir and Adleman)
Symmetric encryption algorithms rely on a "shared secret" among the parties,
the secret key, which can be used both for encrypting and decrypting a
message. Public key algorithms rely on two keys, one for encrypting, the
other for decrypting. If the parties publish their encryption keys (public
keys), while keeping their decryption keys secret (private keys), the sender
can use the recipient's encryption key to send a message that only the
recipient can decrypt with his private decryption key. Public key
cryptography largely eliminates the need for shared secrets.
Another issue would be, can somebody record the communication today and play
it back tomorrow. This can be excluded by adding time stamps to the encrypted
message.
- Why should I use SSH?
Currently, much of the communication over computer networks is still done
without encryption. As a consequence, anyone who has access to a machine
connected to the network between computers A and B can listen in on any
communication going on between A and B. This can be done by hackers, curious
administrators, employers, criminals, industrial spies, and governments. Some
networks leak enough electromagnetic radiation that data may be captured even
from a distance. We are not concerned with spies and the government, but we
are concerned with hackers. Hackers can do significant damage. See
here for a longer discussion
why security is so important.
When you log into a remote computer (to work interactively with telnet, or to
read your email with Eudora, or to transfer files with
ftp), all data including passwords are sent across the network unencrypted.
Thus, any listener on the network can capture your username and password (by
running a sniffer, i.e. a program that captures and stores usernames and
passwords) and use them to subsequently gain access to your account. The
hacker can then delete or modify data, deny service to the computer's
legitimate users, attack other sites and run sniffers on the local network to
collect even more usernames and passwords. Sniffer programs and other exploit
scripts are readily available on the Internet and can be downloaded and used
by any bored teenager. No technical knowledge is required to run them.
Furthermore, it is possible to hijack connections going though the network in
the clear. An intruder can enter into an existing connection and start
modifying data in both directions. This can, for example, be used to insert
new commands in sessions already authenticated. Consequently, no security
method based merely on authenticating the user is safe.
Encryption and cryptographic authentication and integrity protection are
required to secure networks and computer systems. SSH uses strong
cryptographic algorithms to achieve these goals.
Ease of use is critical to the acceptance of a piece of software. SSH
attempts to be easier to use than its insecure counterparts.
- What kinds of attacks does SSH protect against?
- IP spoofing, where a remote host sends out packets which pretend to come
from another, trusted host. SSH even protects against a spoofer on the local
network, who can pretend he is your router to the outside.
- IP source routing, where a host can pretend that an IP packet comes from
another, trusted host.
- DNS spoofing, where an attacker forges name server records.
- Interception of cleartext passwords and other data by intermediate
hosts.
- Manipulation of data by people in control of intermediate hosts
(man-in-the-middle attacks).
- Attacks based on listening to X authentication data and spoofed
connection to the X11 server.
SSH never trusts the net. A hacker who has taken over the network can only
force SSH to disconnect, but cannot decrypt or play back the traffic, or
hijack the connection.
- What kinds of attacks does SSH not protect against?
- SSH will not help you with anything that compromises your host's security
in some other way. Once an attacker has gained fully privileged access to a
machine (e.g. root access on a Unix computer, or administrator access on an
NT machine), they can then subvert SSH, too.
- If you use RSA authentication and somebody malicious has access to your
home directory, then security is nonexistent.
G. Raimann
|
|
|
