OpenSSH is the open source version of SSH, or Secure Shell. Connectivity tools such as Telnet and FTP are well-known, but they send data in plain text format, which can be intercepted by someone using another system on the same network, including the Internet. On the other hand, all data transferred using OpenSSH tools is encrypted, making it inherently more secure. The OpenSSH suite of tools includes ssh for securely logging in to a remote system and executing remote commands, scp for encrypting files while transferring them to a remote system, and sftp for secure FTP transfers. OpenSSH uses a server-client relationship. The system being connected to is referred to as the server. The system requesting the connection is referred to as the client. A system can be both an SSH server and a client. OpenSSH also has the added benefits of X11 forwarding and port forwarding. X11 forwarding, if enabled on both the server and client, allows users to display a graphical application from the system they are logged in to on the system they are logged in from. Port forwarding allows a connection request to be sent to one server but be forwarded to another server that actually accepts the request. This section discusses how to use OpenSSH, both from the server-side and the client-side.
Configuring the Server
The openssh-server RPM package is required to configure a Red Hat Enterprise Linux system as an OpenSSH server. If it is not already installed, install it with Red Hat Network “Operating System Updates.”
After it is installed, start the service as root with the command service sshd start. The system is now an SSH server and can accept connections if the server allows connections on port 22. To configure the server to automatically start the service at boot time, execute the command chkconfig sshd on as root. To stop the server, execute the command service sshd stop. To verify that the server is running, use the command service sshd status.
Retaining Keys After Reinstalling
When the OpenSSH server package is installed, server authentication keys are generated. The keys are generated when the OpenSSH server package is installed and are unique to the server. They are used to verify that the server being connected to is the intended server. The first time a client connects to an OpenSSH server, it must accept the public key. If accepted, the client stores the public key and uses it to verify the identity of the server with each connection.
When a system acting as an OpenSSH server is reinstalled, the files storing the OpenSSH identification keys are re-created as well. Because the SSH clients use these keys to identify the server before connecting to it, they will see the warning message in Listing after the operating system reinstallation, which generates new keys.
LISTING Warning About Keys Not Matching
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/tfox/.ssh/known_hosts to get rid of this message.
Offending key in /home/tfox/.ssh/known_hosts:73
RSA host key for 172.31.0.1 has changed and you have requested strict checking.
Host key verification failed.
After the message is displayed, the program exits. If you are sure that the key on the server changed, edit the known_hosts file in the .ssh directory of your home directory such as /home/tfox/.ssh/known_hosts. The warning message gives the line number that contains the stored key for the server, or you can search for the hostname or IP address of the server, whichever one you use to connect to it. Delete the line, save the file, and exit the text editor. The next time you try to connect to the server via SSH, you will need to accept the new RSA server key.
Instead of communicating a new key to users every time a server is reinstalled, an administrator can retain the host keys generated for the system before reinstalling. To save the keys before reinstalling, save the /etc/ssh/ssh_host*key* files on another system or backup media. After reinstalling, restore these files to their original locations on the server to retain the system’s identification keys. If this process is used, clients will not receive the warning message when trying to connect to the system after it is reinstalled.
Connecting from the Client
This section discusses how to connect to an SSH server from a Red Hat Enterprise Linux system. The SSH server can be any server running an SSH daemon, including a Red Hat Enterprise Linux system running OpenSSH. To connect to an SSH server, the openssh-clients RPM package must be installed. Install it via Red Hat Network if it is not already installed. This package provides the SSH utilities discussed in this section and summarized in Table.
TABLE OpenSSH Client Utilities
OpenSSH Utility Description
ssh Securely log in to a remote system or execute a command on a remote system
slogin Alias to the ssh command
scp Copy files from one computer to another while encrypting the data
sftp Securely transfer files from one system to another
ssh-add Add RSA or DSA identities to the authentication agent
ssh-agent Remember private keys for public key authentication
ssh-keyscan Gather public SSH keys
Logging In to a Remote System
The most common OpenSSH utility is ssh, a secure replacement for rlogin, rsh, and telnet. The ssh command allows users to remotely log in to a system from another system using an encrypted transfer protocol. Every transfer starting with the username and password sent for authentication is encrypted so it can’t be easily read if intercepted. The system being connected to is considered the server. The system being connected from is called the client. To log in to a system with ssh, use the following command, where <hostname> is the hostname, fully qualified domain name, or IP address of the remote system:
If the hostname or fully qualified domain name is used, the client must be able to resolve it to a valid IP address. The first time a user tries to connect via ssh to another system, the message in Listing is displayed.
LISTING Connecting to an SSH Server for the First Time
If the user types yes, the client saves the server’s public RSA key, and the server responds by requesting the user’s password. If the correct password is entered, the server accepts the request, and the user receives a shell prompt to the remote system. The server’s public key is added to the .ssh/known_hosts file in the user’s home directory. After this public key is written to this file, the message in Listed is no longer displayed when a connection is requested.
When the ssh command is executed, the username of the user currently logged in to the client is sent to the remote server as the username requesting connection. To use a different username on the remote server, use the command ssh username@<hostname>.
Executing a Command Remotely
The ssh utility also allows users to execute commands remotely using the following syntax:
ssh <hostname> <command>
If the command contains any wildcards, redirects, or pipes, it must be in quotation marks such as the following:
ssh myserver.example.com “cat /proc/cpuinfo | grep flags”
After authenticating with a password or passphrase, the results of <command> are displayed to the client.
Transferring Files Securely
The scp utility provides the ability to transfer files from one system to another system running an SSH server such as OpenSSH. The command has many variations, but the basic syntax is as follows:
scp <local-file> <username>@remote.example.com:<remote-file>
Like ssh, if a username is not specified for the remote server, the current username is assumed. If only a directory path is given for <remote-file>, the same filename is used to transfer the file to the specified directory on the remote server. The wildcard character * can be used to specify multiple files for <local-file> and <remote-file>.
The scp command can also be used to transfer remote files to the local system. Just reverse the syntax:
scp <username>@remote.example.com:<remote-file> <local-file>
A few command-line options to scp, such as -l, limit the amount of bandwidth it is allowed to use. Refer to its man page with the man scp command for a full list with descriptions.
The sftp utility can also be used to transfer files via an encrypted connection. It differs from scp and is similar to ftp in that it uses an interactive shell. To connect via sftp to a remote system, use the command sftp username@<remote-system>. Again, if no username is specified, the username of the current user on the client is assumed for the remote system. After authenticating correctly, the sftp> prompt is displayed, giving the user an interactive session to the remote system (see Listing). The interactive commands are similar to ftp. Table lists common sftp commands.
LISTING sftp Session
Connecting to fileserver.example.com...
TABLE Common sftp Commands
sftp command Description
pwd Display current remote directory
lpwd Display current local directory
cd <directory_name> Change to remote directory
lcd <directory_name> Change current local directory
get <file> Retrieve <file> from current remote directory to current
mget <files> Retrieve multiple files
put <file> Upload local file to the current remote directory
mput <files> Upload multiple local files to the current remote directory
ls List files in current remote directory
exit Close connection to SSH server and exit
As you can tell, the commands are similar to ftp with a few exceptions, such as the user is not prompted to confirm actions by default—there is no need to disable prompting with the prompt command before using mget and mput. Hash marks can’t be displayed to show progress, but progress in terms of percentage of total transfer, total kilobytes already transferred, transfer rate, and time remaining is automatically displayed, as in the following:
/tmp/samplefile 100% 1888KB 1.8MB/s 00:01
It is also possible to connect to an FTP server using sftp from the Nautilus file browser. Select Places, Connect to Server from the desktop menu, and select SSH as the service type. Type the IP address or full hostname of the FTP server in the Server field as shown in Figure.
An icon will appear on the desktop using the name of the server or, if provided, the name in the Name To Use For The Connection field. A shortcut is also listed under the Places menu item in the desktop menu. Double-clicking on the desktop icon or selecting the shortcut item in the Places menu will open a file browser window with the files from the FTP server. Depending on your file permissions from the server, you can open, copy, delete, rename files and directories, and more. To unmount the share, right-click on its desktop icon and select Unmount Volume. If the share is not unmounted, it will remain in the Places menu on reboot, but you must reauthenticate to access the share after rebooting.
Creating a Passphrase
Instead of using a password to authenticate, OpenSSH allows the use of a passphrase. Why use a passphrase? Unlike a password, a passphrase can contain spaces and tabs and is usually much longer than a password, hence the word phrase in the name. The added length along with the spaces and tabs makes a passphrase more secure and harder to guess. Passphrases are unique per user and must be created by each user while logged in with the corresponding username. Red Hat Enterprise Linux 5 uses SSH Protocol 2 and RSA keys by default. To generate an RSA key pair for SSH version 2, use the following command:
ssh-keygen -t rsa
As demonstrated in Listing, press Enter to accept the default location of $HOME/.ssh/id_rsa after the key pair is generated. When prompted for a passphrase, type a passphrase to use and type it again to confirm. The passphrase should be different from the user’s password and should contain a combination of numbers and letters to make it more secure. Remember it can contain spaces and tabs. The RSA public key is then written to $HOME/.ssh/id_rsa.pub while the private key is written to $HOME/.ssh/id_rsa.
LISTING Generating a Passphrase
After successfully generating the key pair, copy the contents of the public key file
$HOME/.ssh/id_rsa.pub to $HOME/.ssh/authorized_keys on all the systems you want to connect to with the SSH tools. If the authorized_keys file already exists, append it with the contents of $HOME/.ssh/id_rsa.pub. If the .ssh/ directory does not exist in your home directory on the remote systems, it must be created so that only you, the owner, can access it. To change the permissions for it, execute the command chmod 0700 $HOME/.ssh on the remote system. The $HOME/.ssh/authorized_keys file on each remote system must have the same permissions as the $HOME/.ssh/id_rsa.pub file created by ssh-keygen. Change its permissions with the chmod 644 $HOME/.ssh/authorized_keys command on each remote system to which you will be connecting.
After creating an RSA key pair and distributing the public key to the remote systems, when the ssh <hostname> command is executed, the user will be prompted for the passphrase used to create the key pair instead of being prompted for a password for authentication.
By default, the OpenSSH daemon (sshd) uses syslog to write messages to /var/log/ messages when sessions are opened and closed for users as well as when an authentication attempt has failed.
To modify the type of messages logged, set the LogLevel directive in the /etc/ssh/
sshd_config file. By default, it is set to INFO. The possible values in order of verbosity are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. DEBUG and DEBUG1 are the same. Logging with any of the DEBUG levels violates user privacy and is not recommended.