Chapter 6 Secure Shell Administration (Reference)

This chapter describes how Secure Shell works from the administrator's point of view and how it is configured. This is a list of the reference information in this chapter.

• A Typical Secure Shell Session

• Configuring the Secure Shell

• Maintaining Known Hosts on a Site-Wide Basis

• Secure Shell Files

A Typical Secure Shell Session

The Secure Shell daemon (sshd) is normally started at boot from the /etc/init.d/sshd script. The daemon listens for connections from clients. A Secure Shell session begins when the user runs the ssh, scp, or sftp command. A new sshd daemon is forked for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange with the client. These session characteristics are determined by client-side configuration files and server configuration files, and potentially command-line parameters. The client and server must authenticate themselves to each other. After successful authentication, the user can execute commands remotely and copy data between hosts.

Session Characteristics

The server-side behavior of the sshd daemon is controlled by keyword settings in the /etc/ssh/sshd_config file and potentially the command-line options when sshd is started. For example, sshd_config controls which types of authentication are permitted for accessing the server.

The behavior on the client side is controlled by the Secure Shell parameters in this order of precedence:

• Command-line options

• User's configuration file ($HOME/.ssh/config)

• System-wide configuration file (/etc/ssh/ssh_config)

For example, a user can override a system-wide configuration Cipher that is set to blowfish by specifying -c 3des on the command line.

Authentication

The steps in the authentication process for Secure Shell are as follows:

1. The user runs the ssh, scp, or sftp command.

2. The client and server agree on a shared session key.

   In v1, the remote host sends its host (RSA) key and a server (RSA) key to the client. Note that the server key is typically generated every hour and stored in memory only. The client checks that the remote host key is stored in the $HOME/.ssh/known_hosts file on the local host. The client then generates a 256 bit random number and encrypts it with the remote host's host key and server key. The encrypted random number is used as a session key to encrypt all further communications in the session.

   In v2, the remote host uses DSA in its host key and does not generate a server key. Instead, the shared session key is derived through a Diffie-Hellman agreement.

3. The local and remote hosts authenticate each other.

   In v1, the client can use .rhosts, .rhosts with RSA, RSA challenge-response, or password-based authentication. In v2, only .rhosts, DSA, and password-based authentication are permitted.

Command Execution and Data Forwarding

After authentication is complete, the user can use Secure Shell, generally by requesting a shell or executing a command. Through the ssh options, the user can make requests, such as allocating a pseudo-tty, forwarding X11 connections or TCP/IP connections, or enabling an ssh-agent over a secure connection. The basic components of a user session are as follows:

1. The user requests a shell or the execution of a command, which begins the session mode.

   In this mode, data is sent or received through the terminal on the client side, and the shell or command on the server side.

2. The user program terminates.

3. All X11 forwarding and TCP/IP forwarding is stopped. Any X11 connections and TCP/IP connections that already exist remain open.

4. The server sends the command exit to the client, and both sides exit.

Configuring the Secure Shell

The characteristics of a Secure Shell session are controlled by configuration files, which can be overridden to a certain degree by options on the command line.

Secure Shell Client Configuration

In most cases, the client-side characteristics of a Secure Shell session are governed by the system-wide configuration file, /etc/ssh/ssh_config, which is set up by the administrator. The settings in the system-wide configuration file can be overridden by the user's configuration in $HOME/.ssh/config. In addition, the user can override both configuration files on the command line.

The command line options are client requests and are permitted or denied on the server side by the /etc/ssh/sshd_config file (see ssh_config(4)). The configuration file keywords and command options are introduced in the following sections and are described in detail in the ssh(1), scp(1), sftp(1), and ssh_config(4) man pages. Note that in the two user configuration files, the Host keyword indicates a host or wildcard expression to which all following keywords up to the next Host keyword apply.

Host-Specific Parameters

If it is useful to have different Secure Shell characteristics for different local hosts, the administrator can define separate sets of parameters in the /etc/ssh/ssh_config file to be applied according to host or regular expression. This task is done by grouping entries in the file by Host keyword. If the Host keyword is not used, the entries in the client configuration file apply to whichever local host a user is working on.

Client-Side Authentication Parameters

The authentication method is determined by setting one of the following keywords to “yes”:

• DSAAuthentication

• PasswordAuthentication

• RhostsAuthentication

• RhostsRSAAuthentication

The keyword UseRsh specifies that the rlogin and rsh commands be used, probably due to no Secure Shell support.

The Protocol keyword sets the Secure Shell protocol version to v1 or v2. You can specify both versions separated by a comma. The first version is tried and upon failure, the second version is used.

The IdentityFile keyword specifies an alternate file name to hold the user's private key.

The keyword Cipher specifies the v1 encryption algorithm, which might be blowfish or 3des. The keyword Ciphers specifies an order of preference for the v2 encryption algorithms: 3des-cbc, blowfish-cbc, and aes128–cbc. The commands ssh and scp have a -c option for specifying the encryption algorithm on the command line.

Known Host File Parameters

The known host files (/etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts) contain the public keys for all hosts with which the client can communicate by using Secure Shell. The GlobalKnownHostsFile keyword specifies an alternate file instead of /etc/ssh/ssh_known_hosts. The UserKnownHostsFile keyword specifies an alternate to $HOME/.ssh/known_hosts.

The StrictHostKeyChecking keyword requires new hosts to be added manually to the known hosts file, and refuses any host whose public key has changed or whose public key is not in the known hosts file. The keyword CheckHostIP enables the IP address for hosts in the known host files to be checked, in case a key has been changed due to DNS spoofing.

Client-Side X11 Forwarding and Port Forwarding Parameters

The LocalForward keyword specifies a local TCP/IP port to be forwarded over a secure channel to a specified port on a remote host. The GatewayPorts keyword enables remote hosts to connect to local forwarded ports.

The command ssh enables port forwarding through these options:

• -L, which specifies the local port to be forwarded to the specified port on the remote host

• -R, which specifies a remote port to be forwarded to the local host and specified port

The ForwardX11 keyword redirects X11 connections to the remote host with the DISPLAY environment variable set. The XAuthLocation keyword specifies the location of the xauth program.

Client-Side Connection and Other Parameters

The NumberOfPasswordPrompts keyword specifies how many times the user is prompted for a password before Secure Shell quits. The ConnectionAttempts keyword specifies how many tries (at one try per second) are made before Secure Shell either quits or falls back to rsh if the FallBackToRsh keyword is set.

The Compression keyword enables compression of transmitted data. The CompressionLevel keyword sets a level of 1 to 9, trading off between speed and amount of compression.

User specifies an alternate user name. Hostname specifies an alternate name for a remote host. ProxyCommand specifies an alternate command name for starting Secure Shell. Any command that can connect to your proxy server can be used. The command should read from its standard input and write to its standard output.

Batchmode disables password prompts, which is useful for scripts and other batch jobs.

KeepAlive enables messages to indicate network problems due to host crashes. LogLevel sets the verbosity level for ssh messages.

EscapeChar defines a single character that is used as a prefix for displaying special characters as plain text.

Secure Shell Server Configuration

The server-side characteristics of a Secure Shell session are governed by the /etc/ssh/sshd_config file, which is set up by the administrator.

Server-Side Authentication Parameters

Permitted authentication methods are indicated by theses keywords:

• DSAAuthentication

• PasswordAuthentication

• RhostsAuthentication

• RhostsRSAAuthentication

• RSAAuthentication

HostKey and HostDSAKey identify files that hold host public keys when the default file name is not used. KeyRegenerationInterval defines how often the server key is regenerated.

Protocol specifies the version. Ciphers specifies the encryption algorithms for v2. ServerKeyBits defines the number of bits in the server's key.

Ports and Forwarding Parameters

AllowTCPForwarding specifies whether TCP forwarding is permitted.

GatewayPorts allows remote hosts to connect to ports forwarded for the client. Port specifies the port number that sshd listens on. ListenAddress designates a specific local address that sshd listens to. If there is no ListenAddress specification, sshd listens to all addresses by default.

X11Forwarding allows X11 forwarding. X11DisplayOffset specifies the first display number that is available for forwarding. This keyword prevents sshd from interfering with real X11 servers. XAuthLocation specifies the location of the xauth program.

Session Control Parameters

KeepAlive displays messages regarding broken connections and host crashes. LogLevel sets the verbosity level of messages from sshd. SyslogFacility provides a facility code for messages that are logged from sshd.

Server Connection and Other Parameters

The AllowGroups, AllowUsers, DenyGroups, and DenyUsers keywords control which users can or cannot use ssh.

The LoginGraceTime, MaxStartups, PermitRootLogin, and PermitEmptyPasswords keywords set controls on users who are logging in. StrictModes causes sshd to check file modes and ownership of the user's files and home directory before login. UseLogin specifies whether login is used for interactive login sessions. Turning this keyword on should not be necessary and is not recommended for the Solaris environment.

Subsystem configures a file transfer daemon for using sftp.

Maintaining Known Hosts on a Site-Wide Basis

Each host that needs to talk to another host securely must have the server's public key stored in the local host's /etc/ssh/ssh_known_hosts file. Although it is most convenient to update the /etc/ssh/ssh_known_hosts files by a script, this practice is heavily discouraged because it opens a major security vulnerability.

The /etc/ssh/ssh_known_hosts file should only be distributed by a secure mechanism as follows:

• Over a secure connection such as Secure Shell, IPsec, or kerberized ftp from a known and trusted machine

• At system install time

To avoid the possibility of an intruder gaining access by inserting bogus public keys into a known_hosts file, you should use the jumpstart server as the known and trusted source of the ssh_known_hosts file. The ssh_known_hosts file can be distributed during installation and by regularly running scripts on the individual hosts that pull in the latest version by using scp. This approach is secure because each host already has the public key of the jumpstart server.

Secure Shell Files

The following table shows the important Secure Shell files and the suggested UNIX permissions.

Table 6–1 Secure Shell Files

File Name	Description	Suggested Permissions and Owner
/etc/ssh/sshd_config	Contains configuration data for sshd, the Secure Shell daemon.	-rw-r--r-- root
/etc/ssh/ssh_host_key	Contains the host private key.	-rw------- root
/etc/ssh_host_key.pub	Contains the host public key. Used to copy the host key to the local known_hosts file.	-rw-r--r-- root
/var/run/sshd.pid	Contains the process ID of the Secure Shell daemon, sshd, which listens for connections (if there are multiple daemons, the file contains the last daemon that was started).	rw-r--r-- root
$HOME/.ssh/authorized_keys	Lists the RSA keys that can be used with v1 to log into the user's account, or the DSA and RSA keys that can be used with v2.	-rw-rw-r-- johndoe
/etc/ssh/ssh_known_hosts	Contains the host public keys for all hosts with which the client may communicate securely. The file should be prepared by the administrator.	-rw-r--r-- root
$HOME/.ssh/known_hosts	Contains the host public keys for all hosts with which the client may communicate securely. The file is maintained automatically. Whenever the user connects with an unknown host, the remote host key is added to the file.	-rw-r--r-- johndoe
/etc/nologin	If this file exists, sshd refuses to let anyone except root log in. The contents are displayed to users who are attempting to log in.	-rw-r--r-- root
$HOME/.rhosts	Contains the host-user name pairs that specifies the hosts to which the user can log in to without a password. The file is used Secure Shell, as well as by the rlogind and rshd daemons.	-rw-r—r-- johndoe
$HOME/.shosts	Contains the host-user name pairs that specifies the hosts to which the user can log in to without a password using Secure Shell only.	-rw-r—r-- johndoe
/etc/hosts.equiv	Contains the hosts that are used in .rhosts authentication and Secure Shell authentication.	-rw-r--r-- root
/etc/ssh/shosts.equiv	Contains the hosts that are used in Secure Shell authentication.	-rw-r--r-- root
$HOME/.ssh/environment	Used for initialization to make assignments at login.	-rw------- johndoe
$HOME/.ssh/rc	Runs initialization routines before the user shell starts.	-rw------- johndoe
/etc/ssh/sshrc	Runs host-specific initialization routines that are specified by an administrator for all users.	-rw-r--r-- root

The following table summarizes the major Secure Shell commands.

Table 6–2 Secure Shell Commands

Command	Description
ssh	A program for logging in to a remote machine and for executing commands on a remote machine. The command is intended to replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel.
sshd	The daemon for Secure listens. This daemon listens for connections from clients and provides secure encrypted communications between two untrusted hosts over an insecure network.
ssh-keygen	Generates and manages authentication keys for ssh.
ssh-agent	A program that holds private keys that are used for public key authentication. ssh-agent is started at the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program. Through the use of environment variables, the agent can be located and automatically used for authentication when users log in to other machines while using ssh.
ssh-add	Adds RSA or DSA identities (keys) to the authentication agent, ssh-agent.
scp	Securely copies files between hosts on a network by using ssh for data transfer. Unlike rcp, scp asks for passwords or passphrases (if they are needed for authentication).
sftp	An interactive file transfer program, similar to ftp, that performs all operations over an encrypted ssh transport. sftp connects and logs into the specified host name and then enters an interactive command mode.