About this series

The typical UNIX® administrator has a key range of utilities, tricks, and systems he or she uses regularly to aid in the process of administration. There are key utilities, command-line chains, and scripts that are used to simplify different processes. Some of these tools come with the operating system, but a majority of the tricks come through years of experience and a desire to ease the system administrator's life. The focus of this series is on getting the most from the available tools across a range of different UNIX environments, including methods of simplifying administration in a heterogeneous environment.

Back to top

Why use OpenSSH?

The standard networking services that you use every day, such as FTP, Telnet, RCP, remote shell (rsh), and so forth, are fine within a closed environment, but the information that you transfer over the network with any of these services is not encrypted. Anybody with a packet sniffer on your network or on a remote machine can view the information as it is exchanged, sometimes even password information.

Furthermore, with all of these services, the options for auto-login during the process are limited, and often rely on embedding the plain text password into the command line to execute a statement, making the process even more insecure.

The Secure Shell (SSH) protocol was developed to get around these limitations. SSH provides for encryption of the entire communication channel, including the login and password credential exchange, and it can be used with public and private keys to provide automatic authentication for logins. You can also use SSH as an underlying transport protocol. Using SSH in this way means that once you have opened a secure connection, the encrypted channel can exchange all types of information, even HTTP and SMTP, using the same, secure communication mechanism.

OpenSSH is a free implementation of the SSH 1 and SSH 2 protocols. It was originally developed as part of the OpenBSD (Berkeley Software Distribution) operating system and is now released as a generic solution for UNIX or Linux® and similar operating systems.

Back to top

Installing OpenSSH

OpenSSH is free software and can be downloaded from the main OpenSSH Web site (see Resources). The OpenSSH system can be built from source code on a range of systems including Linux, HP-UX, AIX®, Solaris, Mac OS X, and many others. You can often find a precompiled binary for your chosen platform and version. Some vendors even provide the OpenSSH kit as part of the operating system.

To build, you need the following:

• C compiler (GNU C compiler (gcc) or similar)
• Zlib -- the compression library
• OpenSSL -- the Secure Sockets Layer (SSL) security library

If you want to work with the default configuration settings, then you use the common build sequence, as shown in Listing 1 below.

$ ./configure
$ make
$ make install

This installs the binaries, libraries, and configuration files into the /usr/local directory, for example, /usr/local/bin for binary and /usr/local/etc for configuration files. If you want to integrate the tools into your main environment, then you might want to specify the --prefix option, which sets the base directory, and the --sysconfdir option, which sets the location of the configuration files:

$ ./configure --prefix=/usr --sysconfidir=/etc/ssh

Some other common options you might specify include:

• --with-tcp-wrappers -- This option is required if you want integration with the TCP wrapper security system.
• --with-ssl-dir=DIR -- This option specifies the location of the OpenSSL libraries.
• --with-pid-dir=DIR -- This option specifies the location of the PID file that stores the process ID for the sshd daemon.
• --with-xauth=DIR -- This option specifies the location of the xauth command used for X authentication.

Once configured, build as normal with make.

With the build and installation process completed, you need to configure your system, starting with creating the SSH keys that uniquely identify your system and enable secure communication between clients and your host. You can run:

$ make host-key

Alternatively, you can perform the steps manually on the command line. You need to create three keys (one for each of the main encryption algorithms: rsa1, rsa, and dsa). For example, Listing 2 shows you how to create an rsa1 key.

$ ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key
Generating public/private rsa1 key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /etc/ssh//ssh_host_key.
Your public key has been saved in /etc/ssh//ssh_host_key.pub.
The key fingerprint is:
43:aa:58:3c:d8:30:de:43:af:66:2a:b2:8d:02:08:86 root@remotehost

The system prompts you for a passphrase. For host keys, you probably don't want a passphrase for the key, so you can just press Return to use a blank (empty) passphrase. Alternatively, you can speed up the process by using the -N option on the command line (see Listing 3).

$ ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
Generating public/private rsa1 key pair.
Your identification has been saved in /etc/ssh/ssh_host_key.
Your public key has been saved in /etc/ssh/ssh_host_key.pub.
The key fingerprint is:
a3:e3:21:4f:b5:9f:ff:05:46:66:bc:36:a1:47:a0:64 root@remotehost

Now repeat the process to create the rsa and dsa keys (see Listing 4).

$ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
$ ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""

Two files are created for each key type: the public key (in the file ending .pub) and the private key. You should ensure that the private keys are readable only by root and the SSH processes -- this should be configured automatically. You might want to copy the public keys to a central location on a Network File System (NFS) share to enable people to add them to the known host keys list.

Finally, you need to start the sshd process and configure it to execute at boot time. For Linux hosts, you can find a suitable init script that you can add to /etc/init.d in contrib/redhat/sshd.init.

Back to top

Using SSH for basic terminal access

The primary role for OpenSSH is the SSH tool, which provides a secure alternative to the Telnet protocol for logging into a UNIX or Linux host remotely.

To connect to a remote host using the standard shell, you can just type the name of the host:

$ ssh remotehost

The system, by default, tries to use your current username as the login name. To use a different login, prefix the hostname and separate the two with the @ sign. For example:

$ ssh mc@remotehost

The system prompts you for the user's password -- this is like Telnet.

The first time you connect to a host, the system asks if you want to keep a copy of the remote hosts public key in your 'known hosts' file (see Listing 5).

$ ssh root@remotehost
The authenticity of host 'remotehost (10.211.55.3)' can't be established.
RSA key fingerprint is cc:c8:8b:75:3d:b6:00:2f:a9:9c:53:4c:03:0f:3d:1b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'remotehost' (RSA) to the list of known hosts.

In the future, you won't get this warning, but a warning is sent if the system detects a difference in the public key returned by the remote host and the public key that you have on file for that host, as this might indicate a potential hacking attempt. It can also mean that the administrator has simply regenerated the host keys.

In essence, there are no differences between an SSH and a Telnet session, except that the SSH session is encrypted, making it almost impossible for somebody to snoop on your session and determine your password or the commands and operations you are executing.

You can also use SSH to run a command directly on a remote host without having to use the shell. For example, see Listing 6 to run the who command on a remote host.

$ ssh mc@remotehost who
admin    console  Nov 23 14:04 
mc       ttyp1    Dec  2 10:53 (sulaco.mcslp.pri)
mc       ttyp2    Dec 10 06:50 (sulaco.mcslp.pri)
admin    ttyp3    Dec 12 13:33 
mc       ttyp4    Dec 15 12:38 (nautilus.mcslp.p)

Remote execution also emulates the standard input, output, and error of the client host. This means that you can redirect output to a remote command. For example, you can append information directly to a remote file by piping the output from the command to an SSH on a remote host (see Listing 7).

$ echo "Hello World" |ssh mc@remotehost 'cat >> helloworlds.txt'

You can use this to your advantage when you simplify the login process when using SSH.

Back to top

Using SFTP to exchange files

The sft command is an FTP-like alternative that uses the secure communication channel provided by the SSH protocol.

To open an SFTP connection, specify the hostname on the command line:

$ sftp remotehost

Remember, the previous command assumes you want to use the same login as on the current host. To use a different login, prefix the username to the hostname:

$ sftp mc@remotehost

Although SFTP works in a similar fashion to FTP, there are some limitations and differences. For example, dir in FTP provides a long listing of files (see Listing 8).

ftp> dir
502 'EPSV': command not understood.
227 Entering Passive Mode (192,168,0,110,150,159)
150 Opening ASCII mode data connection for directory listing.
total 1472
drwx------   3 mc        staff   102 Nov  4 11:17 Desktop
drwx------   3 mc        staff   102 Nov  4 11:17 Documents
drwx------  18 mc        staff   612 Nov  5 18:01 Library
drwx------   3 mc        staff   102 Nov  4 11:17 Movies
drwx------   3 mc        staff   102 Nov  4 11:17 Music
drwx------   4 mc        staff   136 Nov  4 11:17 Pictures
drwxr-xr-x   4 mc        staff   136 Nov  4 11:17 Public
drwxr-xr-x   6 mc        staff   204 Nov  4 11:17 Sites
drwxrwxrwx   3 root      staff   102 Dec 24 07:30 tmp
drwxr-xr-x   7 root      staff   238 Dec 11 08:39 trial
226 Transfer complete.

Within SFTP, dir works as an alias for the hosts directory listing command, which on UNIX or Linux is ls. By default, dir provides only a short listing (see Listing 9).

 
sftp> dir
Desktop    Documents  Library    Movies     Music      Pictures   Public     
Sites      tmp        trial

For a long listing, use the same options as you would with ls (see Listing 10).

sftp> dir -l
drwx------    3 mc       staff         102 Nov  4 11:17 Desktop
drwx------    3 mc       staff         102 Nov  4 11:17 Documents
drwx------   18 mc       staff         612 Nov  5 18:01 Library
drwx------    3 mc       staff         102 Nov  4 11:17 Movies
drwx------    3 mc       staff         102 Nov  4 11:17 Music
drwx------    4 mc       staff         136 Nov  4 11:17 Pictures
drwxr-xr-x    4 mc       staff         136 Nov  4 11:17 Public
drwxr-xr-x    6 mc       staff         204 Nov  4 11:17 Sites
drwxrwxrwx    3 root     staff         102 Dec 24 07:30 tmp
drwxr-xr-x    7 root     staff         238 Dec 11 08:39 trial

Other commands, changing directories (cd and lcd for local), creating directories (mkdir), and sending (put) and receiving (get) files remain the same. For the latter commands, put and get both accept wildcards (like mput and mget in FTP), but be careful when transferring multiple files without a wildcard within SFTP. For example, sftp> mget file1 file2 file3 is identified as an attempt to obtain file1 and file2 and place them into the local directory file3, which probably won't exist.

Back to top

Using scp to copy files between hosts

The scp command works like the rc command, except that files are transferred using the SSH protocol. This makes scp a much better option when transferring content-sensitive files, or when exchanging files automatically over the Internet.

The format is similar to rcp; you specify the file paths copy between incorporating the hostname, if necessary, into the path. For example, to copy the .bashrc file from remotehost to the local machine, use:

$ scp remotehost:/users/mc/.bashrc ~/.bashrc

As before, to specify the username to use, prefix the host with the username and the @ sign:

$ scp mc@remotehost:/users/mc/.bashrc ~/.bashrc

The ~ meta-character should also work to access information from a home directory, providing the user you are using to connect has rights to read it:

$ scp mc@remotehost:~mc/.bashrc ~/.bashrc

To copy from the home directory of the user you are logging in as, use:

$ scp mc@remotehost:.bashrc ~/.bashrc

The scp command also supports standard expansion rules. So to copy all of the .bash* files, you might use:

$ scp mc@remotehost:.bash* ~

Or you can be even more specific and select individual files using brace ({}) expansion:

$ scp mc@remotehost:".bash{rc,_path,_aliases,_vars}" ~

Note that the brace expansion of the file path, not the full remote path expression, has been enclosed in double quotes.

In all of the above cases, the system prompts you for a password for the remote host. You can avoid this by providing the host with the public portion of your own personal key.

Back to top

Enabling automatic login using public keys

When you log in to a remote system with ssh, sftp, or scp, you still need to use your password to complete the login process. Once you have exchanged a valid key with a remote site by creating a public or private key and providing the public portion of the key into the ~/.ssh/authorized_keys file, you can eliminate this requirement and allow automatic logins.

To create the public or private key, you need to use ssh-keygen, specifying the type of key encryption. The rsa key type is used in the demonstration, but other key types are also valid. See Listing 11 to create the key.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):

You should enter the location of the file where you want to save the key (both the public and private components). Using the default (within the .ssh directory in your home directory) is usually fine (see Listing 12).

Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):

If you enter a passphrase at this stage, you create a secure keyfile, but you also have to enter the passphrase each time you use the key. Pressing Return means that no password is required (see Listing 13).

Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
98:da:8d:48:a8:09:44:b1:b3:62:51:2d:a9:6b:61:ba root@remotehost

A public key (id_rsa.pub) and the corresponding private key (id_rsa) have been created.

To enable automatic login, you must copy the contents of the public key into the authorized_keys file within the ~/.ssh directory of the remote host. You can do this automatically using SSH (see Listing 14).

$ cat ./.ssh/id_rsa.pub | ssh mc@remotehost 'cat >> .ssh/authorized_keys';

Better still, if this is something that you do regularly across a range of hosts, you can use a small script or shell function that performs all of the necessary steps for you, as shown here in Listing 15.

OLDDIR='pwd';
if [ -z "$1" ]; then
    echo Need user@host info;
    exit;
fi;
cd $HOME;
if [ -e "./.ssh/id_rsa.pub" ]; then
    cat ./.ssh/id_rsa.pub | ssh $1 'cat >> .ssh/authorized_keys';
else
    ssh-keygen -t rsa;
    cat ./.ssh/id_rsa.pub | ssh $1 'cat >> .ssh/authorized_keys';
fi;
cd $OLDDIR

Using the setremotekey script, you can copy an existing key or, if it doesn't already exist, create one before copying:

$ setremotekey mc@remotehost

Now, whenever you need to log in to a remote host with your public key, you can use the script of your personal key with the list of accepted keys for the user on the remote host.

Back to top

Summary

OpenSSH is an important tool that keeps the communication and transfer of information between machines secure. Not only does it provide a secure alternative to common tools like Telnet, FTP, and RCP, it can also act as a transport protocol for other services like Subversion, X Windows System, and rsync. In this article, you've had a look at the basic steps required to get up and running, how to get the best out of the main tools provided by OpenSSH, and how to use the key exchange facility to simplify your login and connectivity issues.

Resources

Learn

• System Administration Toolkit: Check out other parts in this series.
  
  
• Check out other articles and tutorials written by Martin Brown:
  • AIX and UNIX zone
  • Across developerWorks
  
  
• "Deploying OpenSSH on AIX" (developerWorks, September 2002): This tutorial provides an extensive guide to setting up and configuring OpenSSH on the AIX platform.
  
  
• "Making UNIX and Linux work together" (developerWorks, April 2006): This article is a guide to getting traditional UNIX distributions and Linux working together.
  
  
• Solaris to Linux Migration: A Guide for System Administrators: Different systems use different tools, and this IBM Redbook helps you identify some key tools.
  
  
• "Exploring the Linux memory model" (developerWorks, January 2006): Learn how Linux uses memory, swap space, and exchanges pages and processes between the two.
  
  
• AIX and UNIX: The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration and expanding your UNIX skills.
  
  
• New to AIX and UNIX: Visit the New to AIX and UNIX page to learn more about AIX and UNIX.
  
  
• AIX 5L™ Wiki: A collaborative environment for technical information related to AIX.
  
  
• Search the AIX and UNIX library by topic:
  • System administration
  • Application development
  • Performance
  • Porting
  • Security
  • Tips
  • Tools and utilities
  • Java™ technology
  • Linux
  • Open source
  
  
• Safari bookstore: Visit this e-reference library to find specific technical resources.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  
• Podcasts: Tune in and catch up with IBM technical experts.
  
  

Get products and technologies

• OpenSSH Web: You can get OpenSSH here.
  
  
• OpenSSL: Download OpenSSL from this site.
  
  
• Zlib: Zlib is part of the Gzip utility suite.
  
  
• AIX toolkit: OpenSSH is now part of the standard AIX toolkit.
  
  
• IBM trial software: Build your next development project with software for download directly from developerWorks.
  
  

Discuss

• Participate in the developerWorks blogs and get involved in the developerWorks community.
  
  
• Participate in the AIX and UNIX forums:
  • AIX 5L -- technical forum
  • AIX for Developers Forum
  • Cluster Systems Management
  • IBM Support Assistant
  • Performance Tools -- technical
  • Virtualization -- technical
  • More AIX and UNIX forums
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• About this series
• Why use OpenSSH?
• Installing OpenSSH
• Using SSH for basic terminal access
• Using SFTP to exchange files
• Using scp to copy files between hosts
• Enabling automatic login using public keys
• Summary
• Resources
• About the author
• Comments

Dig deeper into AIX and UNIX on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers