11.4 The Secure Shell

The Secure Shell (SSH) lets you connect to a system from another system via TCP/IP and obtain a shell prompt, from which you can issue commands and view output in a secure fashion. SSH works similarly to the older and possibly more familiar Telnet service, but differs in that conversations between SSH and its clients are sent in encrypted form so hackers cannot easily discover private information, including user account names and passwords.

11.4.1 Installing SSH

The installation procedure automatically installs an SSH client and server and associates the sshd service with runlevels 3-5. You can start, stop, and restart the sshd service and changes its associations with runlevels by using the Service Configuration Tool. The service must be running in order to respond to clients.

The SSH service has several configuration files, residing in /etc/ssh. You don't have to modify them to get SSH running. If you're curious about them, view the sshd manpage.

11.4.2 Using SSH

To verify that the SSH server is properly running, you can access it via a client on the local system by issuing the following command:

$ ssh localhost

The client will attempt to log you on to the local system using your current user account and will prompt you for your password. If you supply the correct password, you should see a shell prompt, indicating that the client and server are functioning correctly. Type exit and press Enter to exit SSH.

To log on to a remote system, simply specify the hostname or IP address of the remote system in place of localhost. If you want to log in to a user account other than one named identically to the account you're using on the local system, issue the command:

$ ssh  userid @ host 

where host is the hostname or IP address of the remote host and userid is the name of the user account you want to use. For example:

$ ssh billmccarty@example.com

You can use the SSH client's scp command to transfer files to or from a remote system running an SSH server. To transfer a file to a remote system, issue a command such as this one:

$ scp  file  userid @ host : destination 

where file is the path of the file to be transferred, host is the hostname or IP address of the remote host, destination is the directory to which the file should be transferred, and userid is your user account on the remote system. If given as a relative path, the destination path is understood as being relative to the home directory of the specified user. For example:

$ scp rhbook_rev.txt billmccarty@example.com:files

To transfer files to your home directory on the remote system, omit the path argument; however, retain the colon or the command will be misinterpreted.

You can specify multiple files to be transferred if you like. You can use shell metacharacters to specify a set of files to be transferred. You can also specify the -r flag, which specifies that scp should recursively copy a directory. For example, the following command copies an entire directory to the remote system:

$ scp -r Desktop billmccarty@example.com:files

To transfer files from a remote system, issue a command based on this pattern:

$ scp  userid @ host : file  path 

where host is the hostname or IP address of the remote system, file is the path of the file to be transferred, path is the destination path of the file, and userid is your user account on the remote system. For example:

$ scp billmccarty@author.example.com:/out/ch12.doc files

This command would log in the user billmccarty to author.example.com/out, retrieve the ch12.doc file, and place it in his files directory.

SSH also provides the sftp command, which lets you transfer files in much the same way the ftp command does. The command has the following form:

$ sftp  user @ host 

The command will prompt for the password associated with the specified user account. For example, to transfer files to and from the host author.example.com, you could issue the following command:

$ sftp billmccarty@author.example.com

After establishing a connection to the specified host, the sftp command presents a prompt that lets you enter commands similar to those supported by the ftp command. Use the help command to learn more about the supported commands.

11.4.3 Using a Windows SSH Client

To log on to your Linux system from a remote system via SSH, you must install an SSH client on the remote system. A suitable client for Windows is Simon Tatham's PuTTY, available at http://www.chiark.greenend.org.uk/~sgtatham/putty. Simply download PuTTY to any convenient directory (the windows directory is a good choice). The program doesn't have a setup script; you can run it by selecting Start Run and typing putty; if the directory in which PuTTY resides is not on the execution path, you must type the drive, path, and filename. Alternatively, you can create a shortcut that spares you the trouble. Figure 11-15 shows PuTTY's main screen.

Figure 11-15. PuTTY's main screen

To use PuTTY to connect to a host, specify the following information:

Hostname

The hostname or IP address of the SSH server.

Protocol

You should select SSH. This causes PuTTY to automatically select port 22, the default SSH port. If the SSH server listens on a different port, specify the nonstandard port by using the Port text box.

Click Open to make the connection to the specified host.

The left pane of PuTTY's screen provides access to several configuration options, such as:

• Key mappings

• Character translations

• Selection, copy, and paste options

• Screen colors

Like most Telnet or FTP clients, PuTTY lets you save configurations so you can quickly connect to often-used hosts. Use the Load, Save, and Delete buttons to manage your list of hosts and associated configurations.

For best results when using PuTTY to view screens that include color, enable the option Use background color to erase screen, found in the Terminal settings.

Another useful Windows SSH tool is WinSCP, which provides a user interface resembling that of a graphical FTP client. Figure 11-16 shows a WinSCP session. To learn more about WinSCP or obtain the program, visit http://winscp.sourceforge.net/eng.

Figure 11-16. The WinSCP SSH client

11.4.4 Using TCP Wrappers to Secure TCP Services

SSH is designed to be secure. Nevertheless, various implementations of SSH have suffered from vulnerabilities that have enabled attackers to compromise systems running SSH. Therefore, unless you need SSH, you should disassociate the service from all run levels, by using the Services Configuration Tool.

If you do need SSH, you can make the service more resistant to attack by restricting the hosts from which SSH will accept connections. To do so, edit the /etc/hosts.allow and /etc/hosts.deny files as explained in the remaining paragraphs of this section.

TCP Wrappers is a networking facility that limits access to certain TCP facilities, SSH among them. Together, the /etc/hosts.allow and /etc/hosts.deny files specify the IP addresses of hosts that are authorized to access TCP services that support TCP Wrappers, including SSH. More precisely, the /etc/hosts.allow file specifies hosts that are authorized; the /etc/hosts.deny file specifies hosts that are not authorized.

By default, the /etc/hosts.allow file has the following contents:

#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#

At the bottom of the file, add a line of the following form specifying the IP addresses of hosts allowed to use the SSH service:

sshd:  127.0.0.1 1.2.3.4  1.2.3.5  1.2.4.

The line consists of the literal sshd: followed by a list of IP addresses, each separated by the next by one or more spaces. An IP address can be specified in shortened form, such as 1.2.4. (notice the trailing dot). This specification permits all IP addresses in the range 1.2.4.0 to 1.2.4.255 to use the SSH service. Your list of IP addresses should generally include 127.0.0.1, so that you can test the SSH server by using that IP address, which is the standard IP address of the local host.

The changes to the /etc/hosts.allow file have no effect until you make the proper change to the /etc/hosts.deny file. By default, the /etc/hosts.deny file has the following contents:

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!

The comment in the file references a "portmap line" that does not appear in the file. Ignore this minor error and add the following line at the end of the file:

sshd: ALL

To configure TCP wrappers to protect another TCP service or services, specify each service on a separate line of the /etc/hosts.allow file. To determine the name by which you should refer to a service, search the file /etc/services and use the name given there. Be sure to test your configuration to ensure that it enables the authorized hosts and blocks others. Also, bear in mind that TCP wrappers can block access to TCP services but cannot generally block access to UDP services.