This method introduces a single point of failure, much like the inetd daemon does for the standard Berkeley services. However, this case is even a little worse because when the portmapper dies, all RPC port information is lost; this usually means you have to restart all RPC servers manually or reboot the entire machine.
On Linux, the portmapper is called /sbin/portmap, or sometimes /usr/sbin/rpc.portmap. Other than making sure it is started from your network boot scripts, the portmapper doesn't require any configuration.
Configuring Remote Login and Execution
It's often very useful to execute a command on a remote host and have input or output from that command be read from, or written to, a network connection.
The traditional commands used for executing commands on remote hosts are rlogin, rsh and rcp. We saw an example of the rlogin command in Chapter 1, Introduction to Networking in the section "Introduction to TCP/IP Networks". We briefly discussed the security issues associated with it in "System Security" and suggested ssh as a replacement. The ssh package provides replacements called slogin, ssh, and scp.
Each of these commands spawns a shell on the remote host and allows the user to execute commands. Of course, the client needs to have an account on the remote host where the command is to be executed. Thus, all these commands use an authentication process. The r commands use a simple username and password exchange between the hosts with no encryption, so anyone listening could easily intercept the passwords. The ssh command suite provides a higher level of security: it uses a technique called Public Key Cryptography, which provides authentication and encryption between the hosts to ensure that neither passwords nor session data are easily intercepted by other hosts.
It is possible to relax authentication checks for certain users even further. For instance, if you frequently have to log into other machines on your LAN, you might want to be admitted without having to type your password every time. This was always possible with the r commands, but the ssh suite allows you to do this a little more easily. It's still not a great idea because it means that if an account on one machine is breached, access can be gained to all other accounts that user has configured for password-less login, but it is very convenient and people will use it.
Let's talk about removing the r commands and getting ssh to work instead.
Disabling the r; Commands
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.
Installing and Configuring ssh
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] 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 ssh daemon
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?
72
OpenSSH was developed by the OpenBSD project and is a fine example of the benefit of free software.