fi Create the remote file authorized_keys
echo Adding public key to SHOST scp {SHOST}:HOME.sshidentity.pub {SHOST}:HOME.sshauthorized_keys
cat HOME.sshidentity.pub | ssh SHOST cat HOME.sshauthorized_keys ssh SHOST chown USER HOME.sshauthorized_keys
ssh SHOST chmod 644 HOME.sshauthorized_keys
Such a script makes a setting of a user access to the target host very easy. The script itself can be improved in many ways, as well.
19.3.4 SSH — Version 2
Secure shell protocol and supporting software continue to develop and improve. The previous text, especially the part that addresses SSH configuration and access setup, primarily refers to the initial
SSH version, known as Version 1. At the moment, the latest SSH version is Version 2, which provides a set of radical improvements over Version 1. To make a difference between versions they
are identified as SSH1 and SSH2 respectively; the same is implemented on binaries and configuration data, they have a corresponding suffix within their names.
SSH2 was totally rewritten and it provides: Better−understood and more secure protocol
• New design and new cryptography and mathematics algorithms
• An integrated secure file transfer
• Support for multiple public key algorithms, including Diffie−Hellman key exchange
• New authentication methods like Pluggable Authentication Modules PAM, integration with
Kerberos, and usage of SecureID •
New design and coding of SSH2 has also had some disadvantages; unfortunately SSH1 and SSH2 protocols are not compatible with each other. Many implemented security and performance
enhancements would not have been possible if protocol−level compatibility with SSH1 had been retained. However, to continue to work with already installed SSH1 clients, SSH2 daemon could be
configured to recognize their appearance and automatically to invoke the SSH1 daemon to provide the requested service in the SSH1 way. Such a solution requires both SSH installations on the
same host at the server side and should work well. Nevertheless, sometimes it could be even easier to upgrade all SSH1 clients to SSH2. The new version offers much more, and it is worth it to
make such a move. Even when we talk about SSH2, we are mostly thinking of late SSH2 releases SSH 2.3.x and up which provide more stable and secure connections. Otherwise, to configure
everything and make it work smoothly could be quite a hard job.
SSH2 provides an easier configuration and much better understanding between client and server during the connection. The first time such a connection is established, client and server exchange
necessary public keys automatically and prepare everything for future sessions. There is no more need for an explicit manual transfer of the public key to enable the communication between hosts at
all; this is accomplished in an elegant way during the first users attempt to access a target host. Afterward the authentication and data transfer is accomplished in the secure way, even in a
nonsecure network environment.
455
[bjlpink home bjl] ssh −l bjl red
Host key not found from database. Key fingerprint:
xubis−fygos−fumon−bakyc−sogeh−gopap−hopub−bymov−ni zig−samus−huxyx You can get a public keys fingerprint by running
ssh−keygen −F publickey.pub on the keyfile.
Are you sure you want to continue connecting yesno?
yes
Host key saved to homebjl.ssh2hostkeyskey_22_red .pub host key for red, accepted by bjl Sun May 06 2001 14:20:15
bjls password:
Users actions are presented in bold italic. The user initiates the SSH connection, and confirms continued connecting. For a successful secure remote login, at the end a users password on the
target host red must be entered. Such a dialogue happens only the first time; once the users key is saved on the originating host pink, each succeeding connection will simply require the password
only. Obviously it is much easier than transferring needed keys manually in advance for every user, and it is equally secure.
Each transferred key is saved as a separate file in the users home directory ..ssh2 keyhosts, instead of as an entry in the single file the case with SSH version 1. It makes handling of this data
easier and flexible. Here is an example:
ls –l homebjl.ssh2hostkeys
total 54 −rw−−−−−−− 1 bjl 20 737 Sep 13 2000 key_22_red.pub
−rw−−−−−−− 1 bjl 20 737 Aug 30 2000 key_22_blue.pub −rw−−−−−−− 1 bjl 20 737 Sep 13 2000 key_22_gray.pub
..... .....
−rw−−−−−−− 1 bjl 20 737 Aug 30 2000 key_22_green.pub
Each file contains a public key for the specified host. Another significant SSH2 improvement is in the authentication area. Authentication itself could be
configured in many different ways, and the default one is password−based. However, in the following text the procedure to set SSH2 host−based authentication will be described. The
reasons to choose this authentication method over others are very simple. First, there are many situations when we have to escape default password authentication between certain hosts and for
specific users, as in the case of centralized monitoring, remote scripts, etc. Second, this authentication method works very well for SSH2 what we cannot say for Version 1, and even for
some early SSH2 releases.
For an easier understanding of the described procedure we will suppose the following:
SSHSERVER is the name of the host with running sshd2 daemon, to which we are trying to connect; the name could be full canonical host name, or short host name if two hosts share
the same DNS domain and DNS is properly set. •
ServerUser is the user name on the host SSHSERVER into which we would like to login.
•
SSHCLIENT is the name of the host with running ssh2 client, where we invoke the connection; the name could be full canonical host name, or short host name if two hosts
• 456
•
The needed SSH2 software is installed on both hosts SSHSERVER and SSHCLIENT and individual host keys are generated on both machines SSH2 automatically generates keys
upon its installation. •
The procedure consists of several steps:
Copy the public key hostkey.pub on SSHCLIENT into SSHSERVER and rename into ssh−dss.pub for this host. Execute on SSHCLIENT:
scp etcssh2hostkey.pub SSHSERVER:etcssh2knownhostsSSHCLIENT.ssh−dss.
pub. Upon password authentication the file with the public key will be copied.
1.
To avoid a possible confusion regarding implemented host names full canonical names vs. short host names, SSH2 could be set to use only full host names. The entry in the sshd2
configuration file etcssh2ssh2d_config:
DefaultDomain this dns domain name
will force the use of full canonical host name. Obviously, we then have to also use full host names.
2.
On the host SSHSERVER, create or update the hidden file .shosts in the home directory for the user ServerUser. The contents of this file have to include the full host name and the
name of the user allowed to log in to this account in this case SSCLIENT and ClientUser:
SSCLIENT ClientUser
3.
On the host SSHSERVER, the sshd2 configuration must include host−based authentication, as well as ssh2 configuration on the client side on the host SSHCLIENT. Both configuration
files SSHSERVER:etcssh2sshd2_config and SSHCLIENT: etcssh2ssh2_config have to have hostbased keyword in the authentication entry:
AllowedAuthentication hostbased, passwd,...
Other authentication methods could be listed in the entry, but the hostbased keyword has to be the first in the line. Also, the rhosts authentication should be prevented; the default
entry:
IgnoreRhosts no
should not be changed. 4.
Each change in the sshd2 daemon configuration requires recycling of the daemon itself:
kill −HUP cat varrunsshd2.pid
This example supposes the process ID − PID of the running sshd2 daemon is kept in the file varrunsshd2.pid, which is not a must and is flavor specific. Probably it is easier to check
for the actually running daemon by executing:
ps –ef | grep sshd2
and determining the PID of the leading sshd2 daemon keep in mind that multiple sshd2 daemons can run simultaneously, and we are looking for the leading one.
5.
457
Chapter 20: Electronic Mail
20.1 E−mail Fundamentals
E−mail is probably the most attractive topic for users. Almost every user on the network uses electronic mail known by its acronym e−mail. Users do not know very much about UNIX, but they
like to use, and they benefit from using, e−mail. Usually this is a love−hate relationship between users and e−mail; users love having an e−mail system, but they hate it when it does not work. This
relationship is exacerbated by the fact that only a few of them have any idea how e−mail actually works and really understand e−mail processes. The most common misunderstanding is to confuse
e−mail with other popular network applications, like telnet or ftp. And when the DNS issue arises during a discussion of e−mail, the confusion is complete.
It is not so easy to explain the principles of e−mail in a few words. For starters, e−mail can be compared to regular ground mail service, or snail mail; this is the most helpful description that we
have. If we use this analogy, though, we should also point out other services analogous to the common network applications: telnet corresponds to the phone service, ftp to fax service, and DNS
is an operator to help to resolve nameaddressphone number relationships.
E−mail is based on several supporting programs and protocols that enable local and networkwide e−mail service. The programs accomplish different tasks sequentially in the e−mail generation,
e−mail transfer transportation, and e−mail delivery; the protocols define rules for the interprogram communications.
There are two categories of e−mail programs: mail user agents, or MUA programs, and mail transport agents, or MTA programs. An MUA agent is any number of programs that users run to
read, reply to, compose, and dispose of e−mail. These include, for example, the original UNIX mail program binmail, the Berkeley mail or its System V equivalent mailx, and freely available
programs like mush, elm, pine, and mh, as well as other commercial programs.
An MTA agent is a program that handles mail delivery for many users and forwards e−mail between machines. The central mail transport program, the one most used today, is sendmail. On UNIX this
is the default MTA program. Other mail programs are implemented around sendmail. sendmail determines and invokes other delivery agents called Mailers to deliver e−mail and to further transfer
e−mail. This is shown in Figure 20.1. Mailers are sometimes considered the third category of e−mail programs and named delivery agents, or MDA programs. In this text mailers are treated
as a part of the MTA program.
458
