لطفا منتظر باشید ...
Configuring SSH
In the Linux world, the most popular secure
login protocol is the Secure Shell (SSH). This protocol uses encryption
technology to digitally "scramble" transmissions so that any data
that might be intercepted on compromised routers or via packets sniffers can't
be descrambled and used, at least not with any technology that's readily
available in 2002. (In theory, a fast enough computer could break SSH's
encryption, but computers capable of doing this either do not exist or are very rare.) In 2002, SSH servers are becoming more
common, although they're not yet universal. Like other login servers, basic SSH
configuration is fairly painless, but there are both startup options and
configuration files you may need to adjust to get the system working in
precisely the way you want. Understanding something of how SSH operates may
help you plan your SSH setup to best effect.
NOTE
align=left border=0> There has been some discussion in 2001
concerning the trademark status of the name SSH.
It is possible that the protocol will acquire a new name in the
not-too-distant future, that one major implementation (SSH) will retain its
name, and that the other major implementation (OpenSSH) will change its name.
This matter appears to be unresolved as I write these words, so I use the
names that are on the products' Web sites. Proposals I have seen for changes
do not involve changing the names of the programs distributed in packages,
just the package names and names used in documentation.
Available SSH
Software
There are two major SSH packages for Linux:
the original commercial SSH ( target="_blank">http://www.ssh.com/products/ssh/ ), which is produced by a company called SSH, and an open source
reimplementation ( http://www.openssh.org ). Many Linux distributions now ship with the latter, but you can
use the former if you prefer. (If you use the original SSH, some uses may
require you to purchase a license, but others allow you to use the software for
free. Consult the SSH license for details.) Distributions that ship with
OpenSSH include Caldera 3.1, Debian 2.2 (in the non-US package set), Mandrake
8.1, Red Hat 7.2, Slackware 7.0, and SuSE 7.3. You can obtain OpenSSH for other
distributions, or the latest version if yours is older, from the OpenSSH Web
site. For simplicity's sake, I use SSH to refer
to any implementation of the SSH protocol, and differentiate this as necessary
when referring to specific packages.
NOTE
align=left border=0> The OpenSSH project is closely associated
with the OpenBSD OS. OpenSSH binaries for other OSs are therefore separated
slightly from the main Web page. Specifically, the page
including the Linux versions. You can download portable source code or
precompiled binaries for Linux.
In December of 2001, version 3.1 of the
original SSH was released. In the same month, OpenSSH 3.0.2 was released. These
version numbers are designed to be comparable; the original SSH and OpenSSH
products support roughly the same features and cryptographic technologies in
their version 3.0.
x products, for instance. Version
3 of the SSH protocol adds Public Key Infrastructure (PKI) support, in which
digital certificates "signed" by certificate authorities verify the
identity of one or both parties in a transaction; smart card support, a
hardware-based system of identity checking; and various other enhancements. Because
the SSH company developed the protocol, they're likely to lead the OpenSSH
project slightly in features.
The original SSH and OpenSSH implementations
interoperate, so you shouldn't have to be concerned with who created the
clients that your server will serve, or who created a server to which you want
to connect. There are occasional incompatibilities between specific versions of
the packages, though, even within a single line. The protocol is designed to
negotiate the maximum common level of the protocol, so an SSH version 2client
can connect to a version 3 server, for example. Of course, such a connection
uses the lowest common denominator level of the protocol.
Most OpenSSH packages come as several
separate files. Most important are the base openssh package and the openssh-client and openssh-server packages that contain clients and servers, respectively. To use any
SSH program, you must install the base package and at least one of openssh-client and openssh-server .
SSH is not yet as widespread a protocol as is
Telnet, so you may need to distribute SSH client software for your users. These
packages are available for many OSs. You can find links to free implementations
of SSH for many OSs at http://www.freessh.org . Many commercial terminal programs for OSs like Windows and MacOS
include SSH support, as well. The main problem in using SSH is not in locating
the SSH clients, but in distributing them and convincing your users to use
them.
Understanding SSH Capabilities
SSH does more than most other remote login
protocols, and in more ways than simply providing encryption. Two extra
features of SSH deserve special attention. First, it can forward or tunnel
network ports between the client and server. This means that the forwarded
protocol benefits from SSH's encryption. Depending on your configuration, this
may be done automatically for X, so that when you log into an SSH server from a
system on which X is running, you can launch X programs without worrying about
setting further options. (
these matters in more detail.) With some extra work, you can tunnel just about
any other protocol you like, providing an encrypted version of that protocol. In
fact, it's even possible to use the Point-to-Point Protocol (PPP) to set up a
network interface that's tunneled through SSH. The result is a Virtual Private
Network (VPN) that's implemented via SSH. The VPN HOWTO document (
The second SSH feature that deserves mention
is the direct implementation of non-login tools. Specifically, the SSH package
comes with a program called scp , which is used for copying files from one computer to another, as
follows:
scp [[ user1 @] host1: ] filename1 [[ user2 @] host2: ][ filename2 ]
This syntax is very similar to that of the rcp program,
which is an r-command program that scp is intended to
replace. Unlike rcp or many other file-transfer tools, such as FTP, scp transfers
the files in an encrypted form and encrypts the username and password. Thus,
it's a good choice for transferring files between computers over an untrusted
network.
For more interactive file transfers, clients
can use the sftp program, which works much like the more conventional text-mode ftp program,
but uses SSH encryption to protect passwords and the contents of data being
transferred. Some GUI FTP clients, such as gFTP (
include support for SSH-based transfers, so it's becoming possible for SSH to
replace both a Telnet and an FTP server from a functional point of view.
The standard SSH server program ( sshd ) handles
both the SSH text-mode login client ( ssh on Linux) and
transfers initiated through scp or sftp . This server also handles port forwarding as implemented via ssh . All this
traffic passes through the standard SSH port, 22.
Setting SSH Startup Options
Whatever implementation of the protocol you
use, the SSH server is traditionally started from a SysV startup script, as
described in
the server can be run from a super server, older versions of the program
imposed a delay when so started because they had to perform some CPU-intensive
operations. Modern versions of sshd , run on modern hardware, typically
impose very short delays when run from a super server, so if you prefer, you
can reconfigure your sshd to run in this waybut be aware you must add the -i argument to
the sshd launch command, as described shortly.
The SSH server program, sshd , accepts
a number of arguments that can modify its behavior. In OpenSSH 3.0.2,
these arguments include:
-d The server normally runs as a daemon, but this option causes it to
run in debug mode, in which it remains in the foreground, processes a maximum
of one connection, and logs additional debugging information. You can increase
the debugging verbosity by including up to three -d arguments.
-D This option causes sshd to not detach as a daemon, but unlike
-d , it doesn't cause the server to enter full debug mode.
-e This option causes sshd to send error output to standard error
rather than to the system log.
-f config-file The server normally uses /etc/ssh/sshd_config as
its configuration file, but you may specify another file using this option.
-i This option tells sshd that it's being run from a super
server (such as inetd or xinetd ). This option is required if you
run sshd in this way.
-p port This option sets the port that the server uses, which is normally
22.
-q This option disables routine logging, which normally includes
connection initiations, authentications, and connection terminations.
-4 Normally, sshd accepts connections using either IPv4 or IPv6 addresses. This
option causes it to accept only IPv4 addresses.
-6 This option causes sshd to accept connections only from
systems with IPv6 addresses.
There are additional options for sshd , most of
which relate to setting details of how encryption is to be handled. Consult the
sshd man page if you need information on these options.
Before you run sshd for the first time,
you need to generate some encryption key files. These files contain the keys
used by SSH's algorithms to identify itself and encrypt data. Most SSH
distributions include code to check for and, if necessary, generate these keys
in their SysV startup scripts for the server. If your system doesn't do this,
try using the following commands:
# ssh-keygen -q -t rsa1 -f /etc/ssh/ssh_host_key -C '' -N '' # ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C '' -N '' # ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_dsa_key -C '' -N ''
Each of these commands generates two keys: a private key used only on the server, and a public key that's given to clients so that they may
send encrypted data to the server. The latter is placed in a file whose
name is based on the name of the former, but with .pub appended. You can check for the existence of these six
files ( ssh_host_key , ssh_host_key.pub , ssh_host_rsa_key , ssh_host_rsa_key.pub , ssh_host_dsa_key , and ssh_host_ dsa_key.pub , all normally in /etc/ssh ) to see if they exist before
running these commands. If you overwrite existing keys, it's possible that
clients that have already been configured to trust the server with the old keys
will need to be reconfigured, so don't replace these keys unnecessarily.
Adjusting
the sshd_config File
The sshd server
is controlled through a file called sshd_config ,
which normally resides in /etc/ssh .
(The ssh client program uses a
configuration file called ssh_config
in the same location; don't confuse the two.) This file consists of options and
values, each pair on a line by itself, thus:
Option value
As with many configuration files, comment lines begin with
pound signs ( # ). Some of the
options mirror options you can set at startup time via command-line arguments.
Others are unique to the configuration file. A default configuration works well
enough for many systems, but you may want to review your configuration file,
especially for certain security-related options like PermitRootLogin . The most important sshd_config options include the following:
Port You
set the port to which sshd
listens using this option. The default value is 22 .
HostKey
This option tells the server where to look for host keys. These are the private
files generated prior to the program's first launch, such as /etc/ssh/ssh_host_key . You can specify
several key files.
KeyRegenerationInterval
SSH negotiates an encryption key when it makes a connection, then negotiates a
new key from time to time thereafter to reduce the damage should a single key
be somehow intercepted or decoded. (These keys are generated in addition to the keys sshd needs before you run it for the first time, and
they're never stored on disk.) This option sets the length of time, in seconds,
between new key generation.
PermitRootLogin
This option defaults to yes on
most installations. This default allows sshd
to accept logins from root . It's
safer to set this value to no ,
because doing so requires that a would-be intruder have two passwords (one for
a normal user, as well as the root
password) to gain root access to
a system via SSH, assuming there are no other security flaws on the system. If
this option is set to no , you
can still use SSH to administer a system remotely, but you must log in as a
normal user and then use su or a
similar program to acquire root privileges.
IgnoreRhosts
This option is normally set to yes ,
which causes sshd to ignore the ~/.rhosts file. If this option is set to no , and if RhostsAuthentication is yes ,
sshd permits authentication
based on a trusted hosts model similar to that used by rlogind . Setting this option to no is generally unwise.
RhostsAuthentication
SSH uses two options to enable rlogind -style trusted hosts
authentication: IgnoreRhosts is
one, and RhostsAuthentication is
the other. The latter enables trusted hosts authentication generally. It's
usually best to set this option to no .
RSAAuthentication
When using version 1 of the SSH protocol, the computer can use a public key
authentication method that permits a login without sending a password by using
a public key file. Alternatively, you can use the public key in conjunction
with a pass phrase to improve security. You can enable this feature by setting
this option to yes , which is the
default.
PubkeyAuthentication
This option works much like RSAAuthentication ,
but applies to SSH protocol version 2.
PasswordAuthentication
If set to yes , this option
permits users to authenticate by sending their passwords at a prompt. This is a
common method of SSH authentication, so you should probably leave it enabled.
X11Forwarding
As mentioned earlier, SSH can be used to tunnel X connections. Both the client
and the server must be configured to do this, though. This option determines
whether the server forwards X connections; set it to yes to enable this feature. The SSH client
must have a similar option set. It's called ForwardX11
in the /etc/ssh/ ssh_config
file.
There are many additional SSH configuration options you can
set. Some of these relate to alternative authentication methods, others
fine-tune options described here, and still others set miscellaneous features.
Many default sshd_config files
include these options, so you can peruse your file to see how your system is
configured. You can also consult the sshd
man page for information on these options.
SSH
Authentication Options
When an SSH client and server communicate, they encrypt all
communications using a variety of encryption methods. In brief, the two servers
agree on a temporary encryption method that they use to exchange public keys, which are long numbers that can be used
in encryption algorithms to encrypt transmissions intended for each other. Each
side also retains for its own use a private key,
which it uses to decrypt data received from the other computer. The systems use
this technique to encrypt the exchange of another type of key, known as a secret key, that's used for another encryption
method. This secret key encryption method, which uses a single key, is faster
than the public/private key method used to exchange the secret key. The
public/private key method exists to protect the secret key from discovery. SSH
also uses a public/private key pair as one of several possible methods of
authenticationconfirming that users are who they claim to be, and not
malicious interlopers.
Understanding
SSH Authentication
From a user's point of view, there are several different
methods that SSH may use to authenticate users. The exact details of these
methods differ from SSH version 1 to SSH version 2, but the systems attempt to
use each of several authentication methods in turn. Specifically:
The client attempts to use trusted-hosts authentication.
This attempt is usually blocked by settings on the server's RhostsAuthentication or IgnoreRhosts configuration options. If
this attempt is successful, though, the user gains access to the server without
having to enter a password.
2.
The client attempts to use a hybrid of trusted-hosts with Rivest/
Shamir/Adleman (RSA) authentication. Again, this attempt usually fails.
3.
The client attempts to use an RSA authentication method in which the
server sends a special server identity file. If this file is stored on the
server, and if subsequent steps in this method work, the user gains access to
the system. Depending on the encoding of the RSA files, the user might have to
enter a pass phrase, or might gain entry without having to type a pass phrase
or password. This method requires per-client and per-user configuration on the
server.
4.
If all other authentication methods fail, SSH asks the user for a
password. This password is sent to the server in an encrypted form, decrypted,
and used to verify the user's identity using the server's normal password
authentication methods.
The server stores its keys in /etc/ssh ;
they're used for all users. SSH clients receive
public keys from specific servers, so that the client may verify the server's
identity at a later date. These keys are stored in a user's ~/.ssh directory, so they're maintained
individually for each user. The first time you connect to a server using ssh , the program notifies you that it's
adding a new key to the file. (With some configurations, you may be asked to
authorize this action.) If the key for the server changes, ssh displays a very noticeable warning
message, like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
The message goes on to provide further details, and will not connect
to the server. If the change was legitimate, you can force a connection by
removing the server's entry from your ~/.ssh/known_hosts
or ~/.ssh/ known_hosts2 file,
depending upon whether you're using SSH protocol version 1 or version 2.
Unlike telnetd ,
sshd doesn't normally use the /bin/login program to handle logins.
Instead, sshd performs this task
itself. (The UseLogin option in sshd_config causes sshd to use login , though.) In some sense, therefore, sshd alone is like the combination of telnetd and login . It's this combination that allows sshd to perform public key authentication;
only by bypassing login will
such alternative authentication methods work.
Generating
Keys to Automate Logins or Improve Security
Individual users may also generate keys to uniquely identify
themselves. These are stored in the ~/.ssh
directory on the client. You can transfer the public key stored here to your ~/.ssh directory on the server to bypass
the need to enter a password, which is the normal method of authentication with
a default configuration of SSH. Alternatively, this method may be used to
increase security by requiring a pass phrase, which in conjunction with the
public key itself may make it more difficult for an outsider to break into your
account. To use this public key authentication for either purpose, follow these
steps:
Log into the SSH client system.
2.
Type the following command, which may take a few seconds to complete,
to generate an SSH version 2 key:
3.
$ ssh-keygen -q -t rsa -f ~/.ssh/id_rsa -C '' -N ''
NOTE
align=left border=0> If you omit the -N ''
option, ssh-keygen will prompt
you for a pass phrase. If you enter anything other than a single carriage
return, you'll have to enter this pass phrase whenever you make a connection
to the server. If you do this, you'll trade the need to enter a password for
the need to enter a pass phrase.
3.
Transfer the ~/id_rsa.pub
file to your account on the server. (Note that this file is the public key, and
was automatically generated along with the private key whose filename you
entered with the preceding command.) You may use the scp command to do this, thus:
4.
$ scp ~/.ssh/id_rsa.pub server:
.ssh/id_rsa.
client
5.
Log into the server. You may use ssh
to do this, but you'll need to enter a password.
6.
Change to the ~/.ssh
directory. If you list the files in this directory, you should see one called id_rsa . client .
7.
Add the client's public key to the authorized_keys2
file. You can do this with the following command:
8.
$ cat id_rsa.client >> authorized_keys2
From this point on, you should be able to connect from the
client to the server using version 2 of the SSH protocols. If you didn't use a
pass phrase, you'll be able to log in without using a password or a pass
phrase, but if you entered a pass phrase when creating your keys, you'll need
to enter it when logging in. You can force the SSH client to use version 2 with
the -2 option, thus:
$ ssh -2 server
WARNING
align=left border=0> If you use public key authentication, your private key
becomes extremely sensitive. If somebody acquires your client's private key
file, that person may be able to masquerade as you. SSH links the private key
to a particular computer, so the interloper can't log in from any IP address,
but crackers have ways around such restrictions, which is part of why rlogind is not very secure. The pass
phrase that was explicitly omitted in Step 2 of the preceding method is
designed to protect the private key; without the pass phrase, the private key
file isn't very useful to a miscreant. Of course, using a pass phrase defeats
the convenience function of this method. On the other hand, using this method
with a pass phrase improves security, because
an intruder would require both your pass phrase and your private key to break
in, assuming no other security problems exist on the server.
You can follow a similar procedure to enable SSH protocol
version 1's RSA authentication. You'll need to implement the following changes
to the procedure:
~/.ssh/id_rsa to -t rsa1 -f
~/.ssh/ identity . This generates a version 1 RSA public/private key
pair rather than a version 2 key pair. You'll need to make appropriate changes
to the filenames throughout the rest of the procedure.
In Step 6, you must copy the public key from identity.pub into authorized_keys , not into authorized_keys2 .
When making the connection, you should omit the -2 option to ssh , which forces use of version 2 of the protocol.
Both of these procedures assume that the server is configured
to accept public key (aka RSA) authentication. As described earlier, these
options are enabled via the RSAAuthentication
(version 1) and PubkeyAuthentication
(version 2) configuration options in /etc/ssh/sshd_config .
It should be emphasized that you don't need to enable public
key authentication. With a default configuration, using SSH without this option
works just fine. Using public key authentication either obviates the need for
entering a password, relying upon the integrity of a key file instead, or
improves security by requiring both a key file and a pass phrase to gain entry
to the system.
Using
ssh-agent
Another option for SSH authentication is to use a tool called ssh-agent along with associated utilities.
This program manages SSH keys so that you only need to enter an SSH pass phrase
once per local session. To use it, follow these steps:
Follow the procedure outlined in the section entitled
"
to create a public/private key pair on your SSH client system and transfer the
public key to your account on the SSH server system. You should be sure to omit
the -N '' option to ssh-keygen , so that you protect your
private key with a pass phrase.
2.
On the SSH client system, type ssh-agent
/bin/bash . This launches the program and a new Bash shell. The ssh-agent program monitors all the
programs you launch from your new shell. (You can use another shell if you
prefer.)
3.
Type ssh-add ~/.ssh/id_rsa
to add the SSH RSA key to the ssh-agent
program's cache of keys. (You can omit the ~/.ssh/id_rsa
option if you use version 1 keys.) Assuming your key is protected by a pass
phrase, ssh-add asks for it at
this time.
At this point, you should be able to reach
your SSH server system by using the SSH client as usual, but you won't be asked
to enter a password or pass phrase. The ssh-agent tool works by
holding keys in memory and setting environment variables that allow the SSH
client to locate ssh-agent to retrieve those keys. Only programs run as children of ssh-agent gain
access to its keys, though, which is why this procedure has ssh-agent start a new Bash shell; the shell and all its children, including ssh when it's
launched from Bash, can manipulate or retrieve these keys.
For a single connection, this approach can
actually complicate matters, because you need to run ssh-agent and
use ssh-add to add keys before you can launch ssh , and you'll still
have to enter your pass phrase once. If you routinely use SSH to log into
several computers using the same key, or if you routinely log in and out of the
same system, however, this procedure can save time, because you'll only have to
enter your pass phrase once. Furthermore, there are some ways you can
streamline the procedure:
your shell via ssh-agent . For instance, if your shell is normally /bin/bash , you
can replace that with /usr/bin/ssh-agent
/bin/bash . (You may need to alter the path to /usr/bin/ssh-agent , and of course you can use other shells if you like.) Thereafter,
you won't need to manually type ssh-agent /bin/bash ;
you can log in, type ssh-add
~/.ssh/id_rsa , and use ssh to log
into the remote system. This method is likely to be useful only if you use
text-mode logins only; in a GUI environment, it creates a new ssh-agent environment
for each xterm window you have open, which is likely to be counter-productive.
If you log in via text mode and start X by
typing startx , you can change this command to ssh-agent startx . This
puts ssh-agent at the root of all your X programs, so it's available to all of
them.
If you use a GUI login, you can copy your .xsession file
(or equivalent) to another name, such as .xsession-nosshagent ,
then create a new .xsession file that includes only the command ssh-agent ~/.xsession-nosshagent . This causes ssh-agent to run as the parent of all your other X processes, so that your
SSH keys, once added using ssh-add , won't need to be re-entered, even if you launch SSH from several
different windows or desktop tools.
Once you've set up ssh-agent and
entered a key, you can view the keys you've entered by typing ssh-add -l ,
or you can delete the keys by typing ssh-add -d . The
latter command configures the system so that you must re-enter the keys (or
enter a password or key in the normal way for SSH) if you try to use SSH again.
One of the advantages of ssh-agent is
that you need not type the key multiple times if you connect to multiple SSH
servers. You must copy the public key to each server, as described in Steps 3
through 6 in "
Security ," whereupon you can use the same
private key loaded in ssh-agent to connect to each system. If you prefer to use different keys for
different systems, you can do so, but you'll need to store them in separate
files and type their associated pass phrases when you load each one. If you try
to connect to a system on which you've not stored your public key, you'll need
to enter a password, just as if you weren't using ssh-agent .
