How to install ssh on Linux?

Building and Installing SSH

For most Unix systems, the installation of SSH is pretty straightforward. Simply download the GNU-zipped tar file from one of the FTP mirror sites listed at (Note: Typically there’s a new version of SSH released every few months.) In order to compile SSH, you need an ANSI C compiler such as gcc. The simplest way to build this software is to do the following:

The configure script should recognize your system type, discover important information about your build environment, and–if everything checks out–create a corresponding Makefile. The make program uses this Makefile to build the software. The make install directive installs the SSH components and man pages in the right places, and generates the initial 1024-bit host key pair (if it doesn’t already exist).

The last thing you’ll have to do is put sshd in in an rc file, so it will launch at startup. On Linux, you’ll want to put it in /etc/rc.d/rc.local, with a syntax like this:

There are other parameters which you can use with sshd, and we’ll look at some of them in the “SSH Components” section.

You’ll also want to enable the port you’re running SSH on. In our case, we’re going to use the default port of 22, so we’ll have to edit our /etc/services file and add a line like this:

As of this writing, SSH has been known to compile on at least thirty-six different Unix flavors, so most of the time you should be able to build it without a hitch. The authors themselves have built it on four different Unix systems without problems. If you have problems during the configuration, compilation, or installation stage, the configure utility may not have recognized your system type, you may need to make some minor configuration changes by hand, or you may need to upgrade some of the tools in your build environment to newer versions. It’s a good idea to read the INSTALL text file to look for any specific problems with your system or environment. For example, there are problems compiling with gcc prior to release, or there may be a problem with schemes that aren’t standardized across Unix systems, such as shadow password implementations. If you encounter a problem not covered in the INSTALL text and are stumped, use some of the resources in the “Getting Help with SSH” section.

SSH Components

The SSH software is comprised of a small suite of utilities that perform different functions. We’re not going to give you an overview of every feature of these utilities. Instead, we’re going to look at functions and parameters that you should know in order to operate an SSH VPN–both those you should use, and those you might be better off not using. For other functionality, we suggest checking the man pages for each of these tools.


The SSH server daemon is called sshd. As shown in the section “Building and Installing SSH,” it’s normally started from an rc file. When launched, it generates the first instance of the server key pair. Because of this, it’s typically not recommended that you start sshd from inetd, because inetd will launch it each time somebody makes a connection. This server key generation adds additional time to the login, sometimes on the order of tens of seconds, depending upon the speed of your machine, its load, and the size of the server key you choose. In some cases this delay will be unacceptable, or at the very least annoying.

sshd has a configuration file called /etc/sshd_config, which lets you set a number of default runtime and security parameters, including port, server key bits, and the types of authentication allowed.

Useful sshd parameters for our purposes

No parameters are normally needed to launch the SSH daemon, but there are a few that can be useful in making modifications.

-b bits: You can set the length of the server key with this option. The default server key is 768-bits, but this option can be used to set it higher if you’re concerned about security at that level. Even though 768-bits is considered relatively safe, key lengths of 1024-bits are generally thought to be safe for the next several years. Using a key-length that is shorter than 768-bits is also possible. If you really wanted to start the SSH daemon from inetd, you could shorten the key length to shorten the generation time, thereby shortening the login time. Key lengths of less than 512-bits, however, are often considered insufficient for business transactions over the Internet. The server key can also be set with the “ServerKeyBits” parameter in the sshd_config file.

-k seconds: Another option that you might want to change is the “-k” option, which will adjust the time to live of the server key. Normally, this key is regenerated every 3600 seconds (one hour), but it can be adjusted to shorter or longer regeneration times. A setting of “0” means that the key will never be regenerated, which isn’t recommended as server key regeneration is an important security feature of SSH. This can also be modified with the “KeyRegenerationInterval” parameter in the SSH daemon configuration file.

-p portsshd is normally run as root on Unix systems on TCP port number 22, but it is possible to launch it as another user if you use the “-p” option to have it listen on a non-privileged port (ports above 1023), and if you specify a different location for the host key file (the default host key file, /etc/ssh_host_key, can be read only by root). For VPN applications there shouldn’t be any need to run the daemon as anyone other than root, though it may be useful in other situations, such as making a secure connection to a system that you don’t have superuser privileges on, and that isn’t already running the daemon. The “Port” parameter in the sshd_config file can also set the default port.

The types of authentication allowed–password, .rhosts, host key, or user key–can be controlled from the sshd_config file.


ssh is the client program, which can also be invoked as slogin. The client can be used either to log in to a host or to execute a program on a remote host, when the host is running sshd. The client is designed to be easy to use and to be run by any user. At the minimum, you can use the following command:

ssh hostname

Which will let you log into a host that’s running sshd. Or, you can execute a remote command with the following syntax:

ssh hostname command

Understanding SSH authentication

Like the r utilities Unix users are familiar with, SSH lets you allow password-free access to a system based on a hostname/username combination in a hosts.equiv file or .rhosts file. In other words, it doesn’t trust network information alone for authentication, as IP addresses and DNS entries can be spoofed. The /etc/hosts.equiv is checked first, and contains hostname and username entries put there by the system administrator. Individual users can also create .rhosts files in their home directories that contain hostname and username entries for hosts they commonly log in from. This file is checked after hosts.equiv, and hosts.equiv can override .rhosts. (Note: Password-free access for root can’t be granted in the hosts.equiv file, only in root’s .rhostsfile.) Unlike the r utilities, SSH won’t allow you to log in password-free based simply on hostname or username. You can specify otherwise at compile time, but this isn’t recommended because it strips SSH of secure authentication. Normally, SSH requires an additional, more secure authentication method in order to proceed.

The default additional method is RSA authentication using host keys. These keys are stored in the system’s /etc/ssh_known_hosts file or the user’s $HOME/.ssh/known_hosts file.

Another additional method is RSA authentication based on a user’s public/private key pair, where the server knows a user’s public key, and the user’s client program knows his private key. In this scheme, a user will store his public keys on a remote host in his $HOME/.ssh/authorized_keys file. When the user connects to the system using ssh, it tells the server which user key pair it would like to use. The server checks to see if that key pair is in the authorized_keys file and, if so, it encrypts a challenge message using the public key and sends it back to the user’s SSH client. The client then decrypts the message using the user’s private key, and sends the message back to the server–thus verifying the user is who he says he is, without ever sending the private key over the network.

Additionally, authentication can be made using a Trusted Information Systems (TIS, recently acquired by Network Associates) authentication server. We won’t go into this type of authentication in this chapter, but information can be found in the README.TIS file that comes with the SSH distribution.

Running ssh in “batch mode”

ssh can also be called from a script in batch mode (see the parameter later in this section) to securely executed automated commands on a remote system. When in batch mode, ssh won’t ask for a password or passphrase as long as password authentication is not needed (as when you’re using RSA user authentication), and as long a passphrase isn’t used to protect the user’s private key. Although this method is less secure, it’s useful in scripts where a user might not be around to supply input. Some security is still maintained because only the user, as the owner of their identity file, can read the private key due to file permissions.

Useful ssh parameters for our purposes

Like sshdssh also has a configuration file, called /etc/ssh_config. By default, everything in the file is commented out. In addition, there are a number of command-line parameters. We’ll look at a few of them here.

-l username: A useful feature of the SSH client is the ability to change the login name you’re using when logging into another machine. Like rsh, it will normally use the name that you’re logged in with on the system you’re connecting from. You can override this with this parameter.

-c cipher: This parameter lets you change the encryption technique that the client is using. As we’ve said, by default it’s IDEA. The types ciphers you can set with this parameter are “idea,” “blowfish,” “des,” “3des,” “arcfour,” and “none.” You can also change this with the “Cipher” parameter in the ssh_config file.

-p port: This allows you to change the default port from 22 to something else, just as in sshd. The “Port” parameter in ssh_config also controls this.

-o option: This allows you to enter a command that includes one of the ssh_config file options for which there might not be a separate parameter. For example, including the configuration file option “BatchMode yes” will keep the client from asking you for a password or passphrase, which is useful in scripts.

-t: This parameter tells the client to force the server to allocate a pseudo terminal, even if the client is being used to run a command remotely. This parameter is important to our VPN setup.ssh-keygen

The ssh-keygen utility can be used by SSH users to generate their RSA user key pair on their client system, or by an administrator to create a host key pair. It’s run straight from the command line, and most users won’t need to include any other parameters. It generates the $HOME/.ssh/identity file for the private key, and the $HOME/.ssh/ file for the public key. Additionally, it asks for a passphrase, which is used to encrypt the private key with 3DES. This means that if someone happened to get a hold of your private key file, they would not be able to read the key unless they also knew your passphrase. 3DES is still considered safe from brute force attacks.

-b bits: This sets the number of bits used in the key pair. It’s 1024-bits by default, which is also recommended.

-f file: This parameter can be used to create a different key file from the defaults.

ssh-agent and ssh-add

The ssh-agent is executed by a user on his or her local machine, and is used in conjunction with RSA user authentication. The purpose of ssh-agent is to hold the private identity keys for a given user. The ssh-add program adds these identity keys to the agent. Running ssh-agent and ssh-add before executing ssh means that you won’t have to enter a passphrase each time you want to execute the client. The passphrase is requested when you run ssh-add, which then decrypts the private key and stores it in memory, and you’re never again asked for it while the agent is running. It can also be used to hold multiple identity keys to enable easy login to multiple machines, where different identities might be used. Why have different identities? One reason might be that security policy at work might dictate the need for a 1024-bit key, while at home or school you can get by with a 512-bit key. In this case you would want an identity for each security level. Another reason is that having multiple identities means that all systems you access won’t be vulnerable if a single identity is compromised. When you have multiple identities, ssh will try each public key within memory until the server accepts one and sends a challenge response.

ssh-agent can be given a command parameter. This command is usually a shell, or the command to start an X Window System environment. ssh-agent will execute this command, and all subsequent commands will be children of the agent. All of these children will have access to the private keys the agent stores, and the keys will be removed from memory once the initial command is exited. In addition, ssh-agent can be called from an “eval” statement within a shell script. Using this method, you do not need to provide a shell as a parameter.

When ssh-add is invoked without parameters, it loads $HOME/.ssh/identity. You can also specify other identity key files (created with ssh-keygen), by specifying the location and name of that file. For instance, you might have one private key for school, another for home, and another for work. In this case, you might issue a command like the following:


The secure copy program, scp, is designed to replace rcp. It can be used to securely copy files between computers using the SSH protocol. It has many of the same functions as rcp, and can even recursively copy files. The invocation normally looks like this:


The make-ssh-known-hosts script can search a domain for all hosts running the SSH daemon, and obtain their public host keys in order to make the /etc/ssh_known_hosts file easily. There are a number of parameters you can use to control its settings. Running it without any parameters will use the domain the host belongs to.