bbrodriges: переводы

→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:

→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.

→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

→#!/bin/sh
for machine in grape lemon kiwi melon
do
rsh $machine /usr/ucb/w
done

→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.

→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.

→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

→[3]
This is true of standard Telnet, but some implementations add security features.

→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.

→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.

→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. 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.
2. On your local machine, invoke the ssh-agent program, which runs in the background.
3. Choose the key (or keys) you will need during your login session.
4. Load the keys into the agent with the ssh-add program. This requires knowledge of each
key's secret passphrase.

→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.

→SSH is a powerful, convenient approach to protecting communications on a computer network.
Through secure authentication and encryption technologies, SSH supports secure remote logins,
secure remote command execution, secure file transfers, access control, TCP/IP port forwarding,
and other important features.

→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.

→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.)

→SSH is popular and convenient, but we certainly don't claim it is the ultimate security solution for
all networks. Authentication, encryption, and network security originated long before SSH and
have been incorporated into many other systems. Let's survey a few representative systems.