1.4. Overview of SSH Features
So, what can SSH do? Let's run through some examples that
demonstrate the major features of SSH, such as secure remote logins,
secure file copying, and secure invocation of remote commands. We use
SSH1 in the examples, but all are possible with OpenSSH, SSH2, and
F-Secure SSH.
1.4.1. Secure Remote Logins
Suppose
you have accounts on several computers on the Internet. Typically,
you connect from a home PC to your ISP, and then use a
telnet program to log into your accounts on other
computers. Unfortunately,
telnet transmits your
username and password in plaintext over the Internet, where a
malicious third party can intercept them.
[3] Additionally, your entire
telnet session is readable by a network snooper.
Terminology: Networking
- Local computer ( local host, local machine)
- A computer on which you are logged in and, typically, running an SSH
client.
- Remote computer (remote host, remote machine)
- A second computer you contact from your local computer. Typically,
the remote computer is running an SSH server and is contacted via an
SSH client. As a degenerate case, the local and remote computers can
be the same machine.
- Local user
- A user logged into a local computer.
- Remote user
- A user logged into a remote computer.
- Server
- An SSH server program.
- Server machine
- A computer running an SSH server program. We will sometimes simply
write "server" for the server machine when the context
makes clear (or irrelevant) the distinction between the running SSH
server program and its host machine.
- Client
- An SSH client program.
- Client machine
- A computer running an SSH client. As with the server terminology, we
will simply write "client" when the context makes the
meaning clear.
- ~ or $HOME
- A user's home directory on a Unix machine, particularly when
used in a file path such as ~/filename. Most
shells recognize ~ as a user's home directory, with the notable
exception of Bourne shell. $HOME is recognized by all shells.
|
SSH completely avoids these problems. Rather than running the
insecure
telnet program, you run the SSH client
program
ssh. To log into an account with the
username smith on the remote computer
host.example.com, use this command:
$ ssh -l smith host.example.com
The client authenticates you to the remote computer's SSH
server using an encrypted connection, meaning that your username and
password are encrypted before they leave the local machine. The SSH
server then logs you in, and your entire login session is encrypted
as it travels between client and server. Because the encryption is
transparent, you won't notice any differences between
telnet and the
telnet-like SSH
client.
1.4.2. Secure File Transfer
Suppose
you have
accounts
on two Internet computers,
me@firstaccount.com and
metoo@secondaccount.com, and you want to
transfer a file from the first to the second account. The file
contains trade secrets about your business, however, that must be
kept from prying eyes. A traditional file-transfer program, such as
ftp,
rcp, or even email,
doesn't provide a secure solution. A third party can intercept
and read the packets as they travel over the network. To get around
this problem, you can encrypt the file on
firstaccount.com with a program such as
Pretty Good Privacy (PGP), transfer it
via traditional means, and decrypt the file on
secondaccount.com, but such a process is
tedious and nontransparent to the user.
Using SSH, the file can be transferred securely between machines with
a single secure copy command. If the file were named
myfile, the command executed on
firstaccount.com might be:
$ scp myfile metoo@secondaccount.com:
When transmitted by
scp, the file is
automatically encrypted as it leaves
firstaccount.com and decrypted as it
arrives on
secondaccount.com.
1.4.3. Secure Remote Command Execution
Suppose
you are a system administrator who
needs to run the same command on many computers. You'd like to
view the active processes for each user on four different
computers --
grape,
lemon,
kiwi, and
melon -- on a local area network
using the Unix command
/usr/ucb/w.
Traditionally, one could use
rsh, assuming that the
rsh daemon,
rshd,
is configured properly on the remote computers:
#!/bin/sh This is a shell script.
for machine in grape lemon kiwi melon On each of these four machines in turn...
do
rsh $machine /usr/ucb/w invoke the "/usr/ucb/w" program, which
done prints a list of all running processes.
Although this method works, it's insecure. The results of
/usr/ucb/w are transmitted as
plaintext across the network; if you consider this information
sensitive, the risk might be unacceptable. Worse, the
rsh authentication mechanism is extremely insecure
and easily subverted. Using the
ssh command
instead, you have:
#!/bin/sh
for machine in grape lemon kiwi melon
do
ssh $machine /usr/ucb/w Note "ssh" instead of "rsh"
done
The syntax is nearly identical, and the visible output is identical,
but under the hood, the command and its results are encrypted as they
travel across the network, and strong authentication techniques may
be used when connecting to the remote machines.
1.4.4. Keys and Agents
Suppose you have accounts on many computers on a network. For
security reasons, you prefer different passwords on all accounts; but
remembering so many passwords is difficult. It's also a
security problem in itself. The more often you type a password, the
more likely you'll mistakenly type it in the wrong place. (Have
you ever accidently typed your password instead of your username,
visible to the world? Ouch! And on many systems, such mistakes are
recorded in a system log file, revealing your password in plaintext.)
Wouldn't it be great to identify yourself only once and get
secure access to all the accounts without continually typing
passwords?
SSH has various authentication mechanisms, and the most secure is
based on
keys rather than passwords. Keys are
discussed in great detail in
Chapter 6, "Key Management and Agents", but for
now we define a
key as a small blob of bits
that uniquely identifies an SSH user. For security, a key is kept
encrypted; it may be used only after entering a secret
passphrase to decrypt it.
Using keys, together with a program called an
authentication
agent, SSH can authenticate you to all your
computer accounts securely without requiring you to memorize many
passwords or enter them repeatedly. It works like this:
- In advance (and only once), place special files called
public key files into your remote computer
accounts. These enable your SSH clients (ssh,
scp) to access your remote accounts.
- On your local machine, invoke the ssh-agent
program, which runs in the background.
- Choose the key (or keys) you will need during your login session.
- Load the keys into the agent with the ssh-add
program. This requires knowledge of each key's secret
passphrase.
At this point, you have an
ssh-agent program
running on your local machine, holding your secret keys in memory.
You're now done. You have password-less access to all your
remote accounts that contain your public key files. Say goodbye to
the tedium of retyping passwords! The setup lasts until you log out
from the local machine or terminate
ssh-agent.
1.4.5. Access Control
Suppose you want to permit another person to use your computer
account, but only for certain purposes. For example, while
you're out of town you'd like your secretary to read your
email but not to do anything else in your account. With SSH, you can
give your secretary access to your account without revealing or
changing your password, and with only the ability to run the email
program. No system-administrator privileges are required to set up
this restricted access. (This topic is the focus of
Chapter 8, "Per-Account Server Configuration".)
1.4.6. Port Forwarding
SSH
can
increase the security of other TCP/IP-based applications such as
telnet,
ftp, and the X Window
System. A technique called
port forwarding or
tunneling
reroutes a TCP/IP connection to pass through an SSH connection,
transparently encrypting it end-to-end. Port forwarding can also pass
such applications through network firewalls that otherwise prevent
their use.
Suppose you are logged into a machine away from work and want to
access the internal news
server at your office,
news.yoyodyne.com. The Yoyodyne network
is connected to the Internet, but a network firewall blocks incoming
connections to most ports, particularly port 119, the news port. The
firewall does allow incoming SSH connections, however, since the SSH
protocol is secure enough that even Yoyodyne's rabidly paranoid
system administrators trust it. SSH can establish a secure tunnel on
an arbitrary local TCP port -- say, port 3002 -- to the news
port on the remote host. The command might look a bit cryptic at this
early stage, but here it is:
$ ssh -L 3002:localhost:119 news.yoyodyne.com
This says "
ssh, please establish a secure
connection from TCP port 3002 on my local machine to TCP port 119,
the news port, on
news.yoyodyne.com." So, in order
to read news securely, configure your news-reading program to connect
to port 3002 on your local machine. The secure tunnel created by
ssh automatically communicates with the news
server on
news.yoyodyne.com,
and the news traffic passing through the tunnel is protected by
encryption. [
Section 9.1, "What Is Forwarding?"]
| | |
1.3. The SSH Protocol | | 1.5. History of SSH |