Olaf Kirch - Linux Network Administrator Guide, Second Edition

Let's talk about removing the r commands and getting ssh to work instead.

Start by removing the r commands if they're installed. The easiest way to disable the old r commands is to comment out (or remove) their entries in the /etc/inetd.conf file. The relevant entries will look something like this:

# Shell, login, exec and talk are BSD protocols.

shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd

login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind

exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd

You can comment them by placing a # character at the start of each line, or delete the lines completely. Remember, you need to restart the inetd daemon for this change to take effect. Ideally, you should remove the daemon programs themselves, too.

OpenSSH is a free version of the ssh suite of programs; the Linux port can be found at http://violet.ibs.com.au/openssh/ and in most modern Linux distributions. [72] OpenSSH was developed by the OpenBSD project and is a fine example of the benefit of free software. We won't describe compilation here; good instructions are included in the source. If you can install it from a precompiled package, then it's probably wise to do so.

There are two parts to an ssh session. There is an ssh client that you need to configure and run on the local host and an ssh daemon that must be running on the remote host.

The sshd daemon is the program that listens for network connections from ssh clients, manages authentication, and executes the requested command. It has one main configuration file called /etc/ssh/sshd_config and a special file containing a key used by the authentication and encryption processes to represent the host end. Each host and each client has its own key.

A utility called ssh-keygen is supplied to generate a random key. This is usually used once at installation time to generate the host key, which the system administrator usually stores in a file called /etc/ssh/ssh_host_key . Keys can be of any length of 512 bits or greater. By default, ssh-keygen generates keys of 1024 bits in length, and most people use the default. To generate a random key, you would invoke the ssh-keygen command like this:

# ssh-keygen -f /etc/ssh/ssh_host_key

You will be prompted to enter a passphrase. However, host keys must not use a passphrase, so just press the return key to leave it blank. The program output will look something like:

Generating RSA keys:…oooooO…oooooO

Key generation complete.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /etc/ssh/ssh_host_key

Your public key has been saved in /etc/ssh/ssh_host_key.pub

The key fingerprint is:

1024 3a:14:78:8e:5a:a3:6b:bc:b0:69:10:23:b7:d8:56:82 root@moria

You will find at the end that two files have been created. The first is called the private key, which must be kept secret and will be in /etc/ssh/ssh_host_key . The second is called the public key and is one that you can share; it will be in /etc/ssh/ssh_host_key.pub .

Armed with the keys for ssh communication, you need to create a configuration file. The ssh suite is very powerful and the configuration file may contain many options. We'll present a simple example to get you started; you should refer to the ssh documentation to enable other features. The following code shows a safe and minimal sshd configuration file. The rest of the configuration options are detailed in the sshd (8) manpage:

# /etc/ssh/sshd_config

#

# The IP adddresses to listen for connections on. 0.0.0.0 means all

# local addresses.

ListenAddress 0.0.0.0

# The TCP port to listen for connections on. The default is 22.

Port 22

# The name of the host key file.

HostKey /etc/ssh/ssh_host_key

# The length of the key in bits.

ServerKeyBits 1024

# Should we allow root logins via ssh?

PermitRootLogin no

# Should the ssh daemon check users' home directory and files permissions?

# are safe before allowing login?

StrictModes yes

# Should we allow old ~/.rhosts and /etc/hosts.equiv authentication method?

RhostsAuthentication no

# Should we allow pure RSA authentication?

RSAAuthentication yes

# Should we allow password authentication?

PasswordAuthentication yes

# Should we allow /etc/hosts.equiv combined with RSA host authentication?

RhostsRSAAuthentication no

# Should we ignore ~/.rhosts files?

IgnoreRhosts yes

# Should we allow logins to accounts with empty passwords?

PermitEmptyPasswords no

It's important to make sure the permissions of the configuration files are correct to ensure that system security is maintained. Use the following commands:

# chown -R root:root /etc/ssh

# chmod 755 /etc/ssh

# chmod 600 /etc/ssh/ssh_host_key

# chmod 644 /etc/ssh/ssh_host_key.pub

# chmod 644 /etc/ssh/sshd_config

The final stage of sshd administration daemon is to run it. Normally you'd create an rc file for it or add it to an existing one, so that it is automatically executed at boot time. The daemon runs standalone and doesn't require any entry in the /etc/inetd.conf file. The daemon must be run as the root user. The syntax is very simple:

/usr/sbin/sshd

The sshd daemon will automatically place itself into the background when being run. You are now ready to accept ssh connections.

There are a number of ssh client programs: slogin, scp and ssh. They each read the same configuration file, usually called /etc/ssh/ssh_config . They each also read configuration files from the .ssh directory in the home directory of the user executing them. The most important of these files is the .ssh/config file, which may contain options that override those specified in the /etc/ssh/ssh_config file, the .ssh/identity file, which contains the user's own private key, and the corresponding .ssh/identity.pub file, containing the user's public key. Other important files are .ssh/known_hosts and .ssh/authorized_keys ; we'll talk about those later in "Using ssh". First, let's create the global configuration file and the user key file.

/etc/ssh/ssh_config is very similar to the server configuration file. Again, there are lots of features you can configure, but a minimal configuration looks like that presented in Example 12.5. The rest of the configuration options are detailed in the sshd(8) manpage. You can add sections that match specific hosts or groups of hosts. The parameter to the " Host " statement may be either the full name of a host or a wildcard specification, as we've used in our example, to match all hosts. We could create an entry that used, for example, Host *.vbrew.com to match any host in the vbrew.com domain.