System Administration Toolkit: Set up remote access in UNIX through OpenSSH

Use OpenSSH to provide a secure environment for running a remote terminal. The basics of OpenSSH and terminal usage are quite simple but, in this article, examine additional elements that allow automatic login to remote hosts, methods for running remote applications, and how to securely copy files between hosts.

Martin Brown (mc@mcslp.com), Freelance Writer, Author

Martin Brown has been a professional writer for more than seven years. He is the author of numerous books and articles across a range of topics. His expertise spans myriad development languages and platforms -- Perl, Python, Java™, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows®, Solaris, Linux, BeOS, Mac OS X and more -- as well as Web programming, systems management, and integration. He is a Subject Matter Expert (SME) for Microsoft® and regular contributor to ServerWatch.com, LinuxToday.com, and IBM developerWorks. He is also a regular blogger at Computerworld, The Apple Blog, and other sites. You can contact him through his Web site.



13 February 2007

Also available in Chinese Russian

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.


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.


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.

Listing 1. Using the common build sequence
$ ./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.

Listing 2. Creating 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).

Listing 3. Using the -N option to speed up the process
$ 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).

Listing 4. Creating the rsa and dsa keys
$ 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.


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).

Listing 5. Known hosts file
$ 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.

Listing 6. Running 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).

Listing 7. Appending information directly to a remote file
$ 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.


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).

Listing 8. dir provides a long listing of files in FTP
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).

Listing 9. dir provides only a short listing in SFTP
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).

Listing 10. Long listing
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.


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.


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.

Listing 11. Creating 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).

Listing 12. Prompt to enter a passphrase
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).

Listing 13. Bypassing the password requirement by pressing the Return key
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).

Listing 14. Enabling automatic login
$ 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.

Listing 15. Using a shell script to enable automatic login
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.


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

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

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=195829
ArticleTitle=System Administration Toolkit: Set up remote access in UNIX through OpenSSH
publish-date=02132007