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.
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.
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 firstname.lastname@example.org
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 email@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 firstname.lastname@example.org: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 email@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 firstname.lastname@example.org
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.
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.
To use PuTTY to connect to a host, specify the following information:
The hostname or IP address of the SSH server.
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:
Selection, copy, and paste options
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.
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.
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 18.104.22.168 22.214.171.124 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 126.96.36.199 to 188.8.131.52 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: