More than ever before, businesses are asking employees to do more with less. Budgets are down, but business demands are continually increasing. One tool that can save you time and help you “work smarter, not harder” is Secure Shell (SSH) authentication keys. SSH is the ubiquitous encrypting TCP/IP utility that lets you remotely access servers—including IBM i—to execute shell commands and perform other functions through securely encrypted TCP/IP tunnels. On IBM i, SSH is part of the free PASE package (5733SC1: IBM Portable Utilities for i5/OS). For details on installing SSH, see “The SSH, SCP and SFTP Tools from OpenSSH.”
SSH keys let you configure access so that automated scripts can securely log in, run commands, or copy files between servers—all without storing passwords on the client host. The alternative—keeping a copy of necessary passwords on each remote host—is a huge security risk because if a client is compromised, the attacker automatically gains access to passwords that totally compromise your server security. An added advantage of SSH is that once you’ve implemented SSH key-based authentication, you can turn off password authentication altogether. This makes your server immune to the continuous barrage of brute force password attacks that are the bane of SSH across the Internet.
SSH is actually a group of three utilities: SSH, Secure Copy (SCP), and Secure FTP (SFTP), all of which use a common program base. Note that on IBM i, the SFTP and SCP clients require SSH key authentication; password authentication isn’t an option. The IBM i SSH client can use either SSH key authentication or ordinary password authentication.
Many people are intimidated by SSH keys and think they’re too complicated to use or understand. But once you grasp the basics of SSH keys and the advantages they provide, you’ll want to start using them immediately.
Most people understand how passwords work. When you try to log in to a server, you provide your user ID, and then the system prompts you for your password. If you supply the correct password, the system allows you to log in to account. Passwords are easy to use and simple to understand; however, they have some serious drawbacks:
- It’s difficult to automate tasks using passwords. For example, the SSH command doesn't support passing a password on the command line. There are some workarounds to this that let you automate passwords, such as the UNIX “expect” utility, but they’re cumbersome and error prone.
- The password must be extracted as “clear text,” making it vulnerable to disclosure.
- Passwords are relatively short and sometimes easy to guess, and SSH password authentication opens your server up to attack by anyone, from anywhere.
- When you log in to a server, your password is sent to the server so that the server can check it. If a server has been compromised, it might record what password you logged in with and then use your password to log in to other servers where you use the same password.
SSH keys can address all of these concerns. In the case of password authentication, users must remember their password (or write it down) and are responsible for not revealing it to anybody—there’s no standard way of protecting the password. SSH key authentication, on the other hand, stores the key somewhere convenient for the user (typically a file protected by the user’s own personal log-in), but in a standardized way that makes accidental disclosure less likely.
Users generally like key-based authentication because by automatically logging the user into servers without requiring a pause to enter the password, it’s more convenient to use in practice. But ultimately, SSH key authentication still depends on the user being careful with SSH key files. There are several ways to do this, as you’ll see shortly. But first you need to understand the two types of SSH keys: public and private.
Public vs. Private Keys
SSH’s key-based authentication uses a mechanism called public key cryptography, a widely used security measure that's the foundation of most Internet encryption today. You can read more about PK, as it’s commonly called, on its Wikipedia page. In a nutshell, though, PK solved a common problem in secure communications: key distribution. For two parties to communicate using cryptographic messages, they must first agree on a mathematical “key” (basically just a unique number) to encode and decode messages. The secret sauce of PK is that it uses two separate keys—one public and one private—so that messages encrypted by one key can only be decrypted by the other, and vice versa. The beauty of this is that the parties don’t need to exchange keys in secret. One party simply publishes their public key to the world, and now anyone can send them a secure message that only the recipient can decrypt.
SSH employs PK, and thus SSH keys are always generated in pairs. Because of the way SSH uses PK, the public key doesn't really need to be published to the world. SSH simply uses the mechanism of PK to enable a secure channel between client and server without using vulnerable passwords. The SSH utility ssh-keygen creates a unique key pair for every client/server combination: a “private key” for the client and a “public key” for the server. These are just text files (each containing a very large number) stored by default in the .ssh directory of your home directory.
On IBM i, you can run SSH commands from the PASE QP2TERM command line environment. You need to first make your own home directory using QP2TERM shell commands (if one isn’t already set up):
chmod 755 /home/brian
You should then change the home directory parameter in your IBM i user profile:
Sign off and back on to allow the changes made to the HOMEDIR parameter to take effect. Note that whenever users enter the PASE or QShell environment, their current path will be from the HOMEDIR parameter.
There are two key algorithm flavors, RSA and DSA, depending on the encryption algorithm you choose. Either algorithm is secure, but DSA is slower at encrypting (it decrypts quickly). RSA is slower at decrypting, so on older servers you might choose RSA to reduce server workload if the primary task is to encrypt files for transmission.
SSH names the private key file id_rsa or id_dsa (depending on if you create an RSA or DSA key). The public key file will be named id_rsa.pub or id_dsa.pub. Because these are just text files, you can display them using any text utility (e.g., the cat or more commands).
The client’s SSH private key can be compared to a physical key that you would use for your house or car. With a physical key, you should be very careful not to lose it, and you should make sure no one has a chance to copy the key. With the SSH private key file, which allows you to authenticate yourself using SSH key authentication, it’s critical that you’re careful with the private key file. It needs to be guarded and protected like you would protect a password.
The SSH public key can be compared to a physical lock. You place the SSH public key on any server you want to be able to log in to with your private key file. You don't need to be as concerned with controlling access to your public key file, and it will generally be on many more servers than your private key file.
Generating an SSH Key
You can generate an SSH key on any server that has OpenSSH—the open source implemenation of SSH—installed on it. If you have a commercial SSH implementation, it will have similar capabilities; you should refer to the vendor’s documentation. OpenSSH ships with all versions of Linux, AIX, Solaris, and other UNIX versions. For Microsoft Windows, the popular PuTTY suite of tools implements an OpenSSH-compatible version of SSH and SCP and contains its own version of ssh-keygen, called PuTTYgen.
When you generate an SSH key pair, you have the option to protect the locally stored private key with a passphrase, encrypting it on a disk to limit access to authorized users and programs. However, choosing this option means that you either need to type the passphrase every time you want to use the private key, or you have to use an SSH agent to cache the decrypted key in memory. Using an SSH agent adds complexity to your security implementation and requires that you manually start the SSH agent (by typing in the passphrase) each time the server is rebooted. Many people choose to not put a passphrase on the private key file, choosing instead to protect the file using native OS file permissions. This lets you automate SSH tasks without manual intervention. However, one scenario in which I would strongly recommend putting a passphrase on a private key is when you create the key to use for your interactive personal account. If you’re using PuTTY as your SSH client, you can use the Pageant SSH agent, which is part of the PuTTY suite of tools.
To generate an SSH key pair, log in to the target server as the user you want to create the key for and run ssh-keygen. When prompted for a location to save the file, press Enter to use the default path (~/.ssh/id_rsa). When prompted for the passphrase, either type a passphrase or press enter to leave the passphrase blank.
By default, ssh-keygen creates an RSA key pair; the private key file will be located at ~/.ssh/id_rsa and the public key file will be located at ~/.ssh/id_rsa.pub. One common misconception is that an SSH key generated on a server is somehow tied to that server. They should be unique for each user, but there’s no problem with sharing the public key among several servers. It’s quite common to generate a public/private key pair on one server, then move the public key to any number of other servers (key files are just text files) and use them there. This greatly simplifies SSH key management without impacting security.
Authorized Keys File
So far in this article, we’ve covered the private and public key files that are generated by ssh-keygen. The other critical file you need to be familiar with is the “authorized_keys” file. The default location for this file is under ~/.ssh/authorized_keys. This file is a list of public SSH keys you would like to grant access to log in to the account. Anyone with the corresponding private key will be allowed to login to the account. The format of the file is one public key per line. Make sure that each public key is on one line and isn't broken up over several lines.
The following are four common scenarios you might run into when setting up SSH keys.
Scenario 1: Setting up the key between two servers (one way). This scenario is the simplest one. In this example, we’ll set up SSH keys so that the account brian on Server1 can log in to the account brian on Server2.
To do this, first run ssh-keygen as the brian user on Server1. The private and public key files will be created under /home/brian/.ssh/id_rsa (private) and /home/brian/.ssh/id_rsa.pub (public). No further work is needed on Server1.
Next, on Server2, create the /home/brian/.ssh directory if it isn't already there. Make sure the .ssh directory has “rwx------” (700) permissions and is owned by the brian account. To set up the /home/brian/.ssh/authorized_keys file on Server2, you can use SCP (authenticating this one time via a password) to copy the public key file from Server1 to Server2, or you can just copy and paste the text of the public key into an editor such as vi on Server2. To use SCP, run a command similar to the following from Server1:
I recommend you create the authorized_keys file with “rw-------” (600) permissions. As previously noted, the authorized_key file is a list of public SSH key files that SSH will grant access to the account.
In summary, this scenario simply requires running ssh-keygen on Server1 to generate the private/public key files, then copying (using scp or just copy/paste) the public key file from Server1 into the authorized_keys file on Server2. This will allow the brian account on Server1 to run commands, copy files, or log in to Server2. However, the brian account on Server2 won’t have any access to Server1, because the brian account on Server2 doesn't have access to the private key file. You can see a visual depiction of this secnario in Figure 1.
Scenario 2: Setting up key between two servers (both ways). This scenario is similar to Scenario 1, but this time we want the brian account on Server2 to have access to Server1 in addition to Server1’s brian having access to Server2.
The first step is the same: Generate the SSH key files on Server1 by running ssh-keygen as the brian account. Next, on Server1, copy the public key file to authorized_keys by running this command:
The final step is to copy the id_rsa, id_rsa.pub and authorized_keys files from Server1:/home/brian/.ssh to Server2:/home/brian/.ssh. As with scenario 1, you can either use SCVP with a password to copy these files or manually create the files with a vi editor and copy/paste the text contents of each file.
Once this is set up, the brian account on Server1 will have access to the brian account on Server2. Conversely, the brian account on Server2 will have access to the brian account on Server1. Figure 2 illustrates this scenario.
Scenario 3: Setting up a key between one server and multiple other servers. This scenario has the private key on Server1 and identical public keys on multiple other servers. This lets you manage multiple servers and run commands on them from one central location (Server1).
Follow the same steps as Scenario 1 to generate the keys, but rather than only copying the public key in authorized_keys on one server, copy it to every server you want to centrally manage from Server1. Figure 3 provides an illustration of this scenario.
Scenario 4: Setting up a key between multiple servers. The last scenario has multiple servers, each with a brian account, where the brian user account on any server must be able to connect to the brian account on any other server.
Follow the same steps as Scenario 2 to generate the keys and create authorized_keys on Server1. However, instead of only copying the private, public, and authorized_keys files to Server 2, copy them to all the other servers.
Now the brian user on any server can authenticate to the brian account on any other server. Figure 4 depicts this secnario.
Adding Options to Your Keys to Improve Security
SSH supports adding options to each key listed in the authorized_key files. You specify options before the key text on each line within the authorized_keys file:
Here are a few security-related options that you might want to consider adding to improve the security of your keys:
- command="<some command>": This option allows you to specify that the key is only valid to run a single command. If you're setting up a key that will only be used for one function, you should consider setting up the key with the command option so that even if the private key is stolen, it will be of limited use.
- from="<IP or hostname>": If you add this option, the key will only be accepted from the specified IP address or address range or specified hostnames. You can separate multiple entries with a comma, and you can specify IP ranges using the CIDR format. For example, you could specify from="192.168.0.0/24" to only allow servers from this network to log in using the key. Using this option increases security because it can keep people out even if your private key file is stolen.
- no-pt: This option prevents SSH from allocating an interactive terminal session, or TTY, to keep the user from running an interactive shell. If you’re setting up a key that will only be used to copy files using SCP or will only be used to run non-interactive commands over SSH, you want to add this option so it isn't possible to use an interactive shell. This security practice is called “least privilege,” and it's a good policy in general.
- no-agent-forwarding, no-port-fowarding, no-X11-forwarding: These options allow you to disable agent forwarding, port forwarding, and X11 forwarding, respectively. If you aren’t using the functionality for these items, they should be disabled.
If you’re using these SSH key options, it’s important to lock down the key as much as possible so that even if the private key is stolen, it’s of very limited use to an attacker.
On Linux and UNIX systems, SSH outputs diagnostic logs to the Syslog facility; with Windows, logging goes to the Application Event Log. On IBM i, each SSH session creates its own log with progress diagnostic messages. If you’re having any problems with SSH key authentication not working, check the log files appropriate to your system. SSH typically does a very good job logging exactly what problem prevented the user from logging in. For example, if you configure the from= option on a key and try connecting from a different hostname/IP address, SSH will log "Authentication tried for user with correct key but not from a permitted host."
Work Smarter with SSH
SSH keys are powerful tools that let system administrators set up authentication between servers in order to save time and automate tasks. Because they’re simple to understand, create, set up, and troubleshoot, you can quickly reap the benefits of using them. Employing these helpful tools will definitely ensure users “work smarter, not harder.”
If you want to learn more about the IBM i implementation of OpenSSH, check out IBM’s Redpaper “Securing Communications with OpenSSH on IBM i5/OS” and the updates in chapters 9-14 of “IBM i5/OS Network Security Scenarios.”