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:
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.
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
do
rsh $machine /usr/ucb/w
done
On each of these four machines in turn...
invoke the "/usr/ucb/w" program, which
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
done
Note "ssh" instead of "rsh"
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?
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, 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:
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.)
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:
[3]
This is true of standard Telnet, but some implementations add security features.
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.
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.)
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]
[3]
This is true of standard Telnet, but some implementations add security features.
No comments:
Post a Comment