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.



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 (, which is produced by a company called SSH, and an open source reimplementation ( 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.



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 contains information on OpenSSH for OSs other than OpenBSD, 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 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. (Chapter 14 covers 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 ( covers such configurations in detail.

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 (, also 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 Chapter 4. Although 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_rsa_key , , ssh_host_dsa_key , and ssh_host_ , 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:

  1. 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:

  1. 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:

     $  ssh-keygen -q -t rsa -f ~/.ssh/id_rsa -C '' -N ''  



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.

  1. Transfer the ~/ 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:

     $  scp ~/.ssh/   server:   .ssh/id_rsa.   client  
  2. Log into the server. You may use ssh to do this, but you'll need to enter a password.

  3. Change to the ~/.ssh directory. If you list the files in this directory, you should see one called id_rsa . client .

  4. Add the client's public key to the authorized_keys2 file. You can do this with the following command:

     $  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  



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:

  • In Step 2, change -t rsa -f ~/.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 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:

  1. Follow the procedure outlined in the section entitled "Generating Keys to Automate Logins or Improve Security" 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:

  • You can edit the /etc/passwd file to call 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 "Generating Keys to Automate Logins or Improve 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 .

Advanced Linux Networking
Advanced Linux Networking
ISBN: 0201774232
EAN: 2147483647
Year: 2002
Pages: 203

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: