Chapter 13: SSH: Secure Shell

Chapter 13

SSH: Secure Shell

In this chapter:

	Understanding ssh, the Secure Shell
	Configuring ssh

In Chapter 12, we discussed the fact that the standard services for interactive sessions on remote machines lack sufficient security and make the server system vulnerable to a wide variety of attacks. The Secure Shell offers strong encryption during authentification and for the whole session, which makes it a perfect replacement for these services. However, ssh has a downside.

Because of the restrictive legal situation involving strong encryption, the11 international version of SuSE Linux omits all applications that use strong encryption, including ssh. However, the German version ships with these tools, and SuSE provides free downloads of RPMs from its German ftp server ftp://ftp.gwdg.de. We highly recommend that you get the ssh package and use it instead of telnet, rlogin, and rsh.

The ssh protocol is handled by /usr/sbin/sshd. This is a stand-alone daemon started by the rc-script /sbin/init.d/sshd. It is started at boot time if the value of START_SSHD in /etc/rc.config is set to yes, which is the default setting in the SuSE ssh package. The first time this script starts sshd, it checks whether a host-key is located in /etc/ssh host key. If not, it generates a random key and stores it in this file. The host key is used to identify the server and prohibit some other machine from claiming to be the one to which you want to connect. After the host key is generated, the service is ready to use.

The sshd daemon reads configuration data from /etc/sshd.config. The file contains keyword-value pairs, one per line. Lines starting with a hash sign (#) and empty lines are interpreted as comments. A decent configuration is shown in the code listing that follows.

This is not the default installed by SuSE; some parameters have been changed in this example as a guide on how to increase security. The sshd daemon with the SuSE default configuration provides encrypted sessions but still allows the authentification scheme used by the r-utilities (rsh, rlogin). The changes will be explained in the descriptions of each keyword. Because the configuration file provided reflects, for the most part, the default settings of the server, the example shown is much shorter; it contains only the parameters that differ from the server defaults.

#  
# This is ssh server systemwide configuration file with  
# increased security.  
#  
PermitRootLogin          no  
IgnoreRhosts             yes  
SyslogFacility           AUTH  
RhostsAuthentication     no  
RhostsRSAAuthentication  yes  
RSAAuthentication        yes  
PasswordAuthentication   no

Rather than listing all possible configurations for sshd we explain only settings used in the example:

	PermitRootLogin Specifies whether the root can log in using `ssh`. May be set to `yes`, `nopwd`, or `no`. The default is `yes`, allowing root logins through any of the authentication types allowed for other users. The `nopwd` value disables password-authenticated root logins. The `no` value disables root logins through any of the authentication methods. ( `nopwd` and `no` are equal unless you have a `.rhosts`, `.shosts`, or `.ssh/authorized_keys` file in the root home directory.) Root login with RSA authentication when the command option has been specified will be allowed regardless of the value of this setting (which may be useful for making remote backups even if root login is normally not allowed). SuSE sets this value to `yes`. You should change it to `no` and use `su` after a regular login to become root on a remote machine.
	IgnoreRhosts Specifies that `.rhosts` and `.shosts` files will not be used in authentication. The default in SuSE Linux is `no`. You may want to set this value to `yes`. This kind of authentification is based on the client's hostname, which can be spoofed in a lot of ways. It's safer not to allow it.
	SyslogFacility Gives the facility code that is used when logging messages from `sshd`. The possible values are as follows: `DAEMON`, `USER`, `AUTH`, `LOCAL0`, `LOCAL1`, to `LOCAL7`. The default is `DAEMON`. SuSE sets this value to `AUTH`, and `syslogd` logs messages of this facility to `/var/log/messages`.
	RhostsAuthentication Specifies whether authentication using `rhosts` or `/etc/hosts.equiv` files is sufficient. Normally, this method should not be permitted because it is not very secure. `RhostsRSAAuthentication` should be used instead, because it performs RSA-based host authentication in addition to normal `rhosts` or `/etc/hosts.equiv` authentication. The default is `no` and should not be changed.
	RhostsRSAAuthenification Specifies whether rhosts or `/etc/hosts.equiv` authentication, together with successful RSA host authentication, is allowed. The default is `yes`, which is reliable because host authentification using RSA algorithms is a trustworthy method and hard to exploit.
	RSAAuthentication Specifies whether pure RSA authentication is allowed. The default is `yes`. This should be your preferred method to log onto other systems. It provides the highest security, because it does not rely only on a password but also works with private and public key couples to ensure that the user is valid.
	PasswordAuthentication Specifies whether password authentication is allowed. The default is `yes`. It should be set to `no` to enforce the much stronger RSA-based authentication.

Many more parameters are supported by sshd. Please refer to the man page sshd(8) to look them up. The client utility to use this service is ssh, which also has an configuration file in /etc/ssh config. Usually, you don't need to change anything in there, and all lines are commented out in the configuration file provided by SuSE. You'll find this file documented in ssh(1).

Chapter 27 discusses the ssh client and covers simple methods to use it as a replacement for the traditional services rsh, rlogin, telnet, and xon.

Summary:

The Secure Shell is an excellent replacement for some standard security services. The ssh service can be used instead of the r-utilities (rlogin, rsh, rcp) and as replacement for telnet. The standard setup of ssh is fine, but can be improved to guarantee a more secure setup.