Establish more effective security capabilities with OpenSSH

Longtime Linux admins know that SSH, the "Secure Shell" protocol, is one of the most handy and potentially critical utilities in their software toolbox. Using multiple terminal emulators in an X Windows environment on a workstation, or via the Screen utility, a sysadmin for Linux or other Unix-based OS servers can manage several systems simultaneously with ease. Network administration shell or Perl scripts can make use of SSH to perform automated tasks on multiple servers at once simply and securely.

Network shell utilities like RSH have been around longer than SSH, of course. But SSH adds strong encryption and data compression to its functionality and most modern SSH implementations also provide SFTP and SCP in the same convenient package, for secure file transfers over the network.

The single most popular and common implementation of SSH comes in the form of OpenSSH, a project conceived and maintained by the OpenBSD community. OpenSSH has been ported to just about every operating system platform under the sun, including Microsoft Windows, though the most common use in a Windows environment is as a client to the OpenSSH server on Unix-based systems such as Linux, Solaris, and OpenBSD.

What SSH does

SSH uses strong encryption to protect a complete remote shell session from malicious security crackers. End-to-end security is provided from the beginning of the session until it terminates, as the client contacts the server and establishes a session-specific encryption key exchange before the username and password are even transmitted from one machine to another. Several different encryption schemes can be used, including AES, 3DES, and Blowfish, among others. While trusted host authentication schemes and previous key exchange between systems can be used to enhance security, OpenSSH does not require certificate or prior key exchange to establish a securely encrypted remote session.

In addition to this, certain types of network traffic can be significantly sped up by use of SSH because of the manner in which it compresses data before transmission. It can provide FTP-like interactive file transfer session capability with encryption via SFTP so that passwords and even usernames are not sent "in the clear" over the network. For more limited, single file transfer operations, SCP similarly provides a secure and easy way to accomplish the task -- an encrypted file copy command that operates over network connections, as a part of most SSH implementations.

SSH is a common and well-known network protocol for stateful encrypted communications. It was originally developed as a replacement for the unencrypted, and thus unsecure, RSH utility, but has gained in functionality over the years until it not only mimics RSH functionality, but extends and improves it, in addition to securing it.

OpenSSH for Linux

Getting OpenSSH installed on the major Linux distributions is as easy as a simple package manager command. For instance, on Debian GNU/Linux, you can install OpenSSH by simply logging in as the root user and entering the command apt-get install ssh. Similarly, on Fedora Core Linux, you can install OpenSSH by logging in as the root user and entering the command yum install ssh. It is highly unlikely that you would even need to do that, however: both Debian and Fedora Core include OpenSSH in their default install configurations. On any Linux system, if you wish to determine whether you have OpenSSH installed, you can find out by simply entering the command ssh. Doing so, if it is installed, produces a brief usage guide message (Listing A):

Listing A

$ ssh
usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
[-D port] [-e escape_char] [-F configfile]
[-iidentity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[user@]hostname [command]

More complete usage information can be found in the OpenSSH manpage. Manpages are part of the traditional UNIX manual documentation system, and to access the OpenSSH manpage on Linux you simply enter man ssh at the command line interface. The page will give you information about command line options for the OpenSSH client, configuration files associated with it, any known bugs in the current version, shell environment variables that affect its operation, and a list of related manpages. As that list indicates, there are also manpages for sshd (the OpenSSH server), ssh-agent (an SSH login management utility), and a number of other utilities in the OpenSSH toolset.

Using and configuring the Linux client

To use the OpenSSH client from the command line to access another system running the OpenSSH server, you typically only need to enter the command ssh host, where "host" is the hostname of the target system. In cases where the hostname cannot be resolved to an IP address because you don't have DNS resolution to that system and it is not listed in the local system's /etc/hosts file, it may be necessary to specify the target system by IP address rather than by hostname, such as ssh 192.168.0.1 for contacting the system at that address. More common SSH command strings follow.

SSH usually uses Port 22. For an SSH server listening on a nonstandard port, use this command, where the example port number is 1234:

Unless a username is specified with the command, it will attempt to log in to the remote system with the same username as the one you're using on the local system. To specify a different username with a command option, you can use the following format where "user" is the username:

A more common means of specifying a username is to use the following format:

You can issue a command on the target system via SSH without opening a shell interface, where "command" in the following example is the command you wish to execute:

To specify a specific directory as the current working directory on the target system, with /home/user as the example directory, you can use the following command format:

Two examples of combining the above options for more complex customised operations follow:

Systemwide OpenSSH configuration files are typically located in the /etc/ssh directory. The main configuration file for the OpenSSH client is /etc/ssh/ssh_config and on most distributions will contain enough comment information to give you an idea of how to use that configuration file. For distributions that have very extensive and comprehensive manpage systems, such as Debian, you can get more information about OpenSSH client configuration with the command man ssh_config.

A common and important configuration option for security purposes is ForwardX11, which should be set to "no" to prevent your SSH client from automatically sending X Window System information across the network, even when you are not using X Windows over the SSH connection. With this set, you can specify that a particular SSH connection should forward X Window System information by using the -X command line option. Other configuration options in the etc/ssh/ssh_config file can also be used to implement, enforce, and comply with your network security policies, and should be investigated as specific security needs arise.

Windows-based SSH clients

There are many SSH clients available for Microsoft Windows systems. Some of these are proprietary, commercial applications, others are "freeware" or "shareware", and still others are open source software like OpenSSH. While command line clients exist, some of which are installed as part of a complete Unix-emulation shell, by far the most commonly used when SSH is all that is needed are graphical user interface clients. Among these, WinSCP for SCP and SFTP capabilities, and PuTTY for SSH shell capabilities, are among the most popular free examples. Having read the preceding information about using the OpenSSH client on Linux, you should find the configuration and user interfaces for WinSCP and PuTTY to be quite easy to understand. An actual port of OpenSSH for Microsoft Windows, appropriately called OpenSSH for Windows, is also available.

Using and configuring the Linux server

In general, the OpenSSH server will already be running on your Linux system. It can be restarted via the command /etc/init.d/ssh restart on Debian GNU/Linux systems. It can similarly be started or stopped by replacing the word "restart" with "start" or "stop", respectively, in that example. Fedora Core Linux systems allow the use of the same command format, but call the service "sshd" in the /etc/init.d directory instead of "ssh".

Similarly to the configuration file for the OpenSSH client, systemwide OpenSSH server configuration is accomplished via the /etc/ssh/sshd_config file. Its format is much the same as that for /etc/ssh/ssh_config, though the options are different. Configuration details can be found using the man sshd_config command.

It is generally a good idea to set the UsePrivilegeSeparation and IgnoreRhosts options to "yes", and set PermitRootLogin and PermitEmptyPasswords to "no". As with the OpenSSH client, forwarding X Windows data over SSH can present a very mild security risk, so it should not be active for any system where it is not needed. As such, it is usually a good idea to set X11Forwarding to "no".

On Linux distributions that are maintained by reasonably security-minded people, these configuration options should mostly be set appropriately. Common exceptions might include the PermitRootLogin and X11Forwarding configuration options.

Using OpenSSH

Additional functionality is available with the use of OpenSSH. For instance, other network protocols can be "tunneled" through the OpenSSH protocol to provide enhanced security, as hinted with references to use of the X Window System over SSH in this article. Tools like ssh-agent can be used to make the management and use of the OpenSSH client even easier. Several apparently unrelated tools include native support of SSH tunneling, such as the Subversion version control system. The possibilities may not be endless, but you will probably never find their end.

New Linux users who use more than one computer on a network sometimes don't immediately see the value of SSH. They usually come from the world of Microsoft Windows, where interfaces are optimised for use by someone sitting in front of the computer to an extent that can make it more difficult to manage them remotely. Even in the cases of server administration and remote technical support, using tools such as Windows Remote Desktop and Terminal Services for Windows, the usefulness of remote management tools is relatively limited and does not encourage much direct use of Windows resources across the network.

By contrast, long-time Linux users sometimes run almost all their day-to-day applications on a single system, and use very lean Linux installs on computers with more modest hardware specifications to access those applications via SSH. Many a Linux sysadmin will, in fact, often spend all day in front of a computer doing pretty much all their work on a computer that isn't even in the same building -- including email, writing, and programming, not just one or two job-specific network applications. Greater familiarity with the capabilities of SSH tends to lead to greater use of it, and greater reliance on it, but people just coming to Linux from Windows may not immediately understand the boost to productivity that SSH can provide.

The configuration and use of OpenSSH is a tool worth learning to use, even if you don't immediately see a use for it. Given time, you may wonder one day how you ever lived without it.