OpenSSH is probably the most widely-used, flexible, multi-purpose cryptographic toolkit on the internet today. If you're using a free OS, it's almost certain that you've got a copy of at least the OpenSSH client installed on your computer.

What is SSH?

SSH is the "secure shell", which is a standard for program execution over the network, generic bidirectional communication, and (with some extensions) file transfer. OpenSSH is a free implementation of this standard. OpenSSH provides a handful of basic tools:

  • ssh, a command-line client for the secure shell protocol -- lets you run commands on remote hosts
  • scp, a (deprecated) command line client for doing simple file and directory copying across the network
  • sftp, a command-line client for doing scripted, bidirectional file transfer securely across the network
  • sshd, a daemon? which you can run on a host to accept connections from any of these clients.

What kinds of authentication can OpenSSH use?

To allow secure remote access, sshd needs to have a robust way to identify users who connect to it. In fact, it has several. Any given instance of sshd will probably have some of these authentication methods disabled. It's up to the administrator of a machine to decide which authentication methods are appropriate.

Password Authentication

This is probably the form of authentication most people are familiar with. The ssh client opens an encrypted tunnel to the server, and then prompts the user for a password (the username has already been determined). It sends these credentials to the server, which checks them for validity.

Public Key Authentication

The ssh client knows about one or more private keys it has access to. It sends the corresponding public keys to the server to see if any of those public keys are acceptable to authenticate to the account. The server checks a file (usually ~/.ssh/authorized_keys) to see if they are, and if they are, it creates a challenge for an acceptable key and sends it to the client. The client uses the private key to compute the appropriate response, authenticating the user.

Challenge/Response Authentication

(i'm not sure exactly how this works, or how it differs from Password Authentication)

Keyboard-Interactive Authentication

The ssh client opens an encrypted tunnel to the server, and the server and the client exchange bytestreams until the server is satisfied. This can be extremely flexible (because arbitrary data can be exchanged), but in the most common configuration (server sends a Password: prompt, client sends back the raw password), it's not advisable, because it means that the server gets to look at the raw password.

Kerberos Authentication (via GSSAPI)

A commonly-applied patchset allows for GSSAPI authentication, which for all intents and purposes means Kerberos? these days. Debian's OpenSSH packages ship with this patch applied and enabled since etch was released.

server authentication

The server requiring the user to authenticate is only one half of a secure connection. To be really secure, the user must also require the server to authenticate itself. SSH provides "host keys" for this purpose. an SSH host key is just like a user's key -- the authentication operation is almost entirely symmetric. However, the user has a responsibility to remember what the key for each server looks like. OpenSSH's client programs do this by storing a list of keys associated with hostnames in ~/.ssh/known_hosts. The first time you try to connect to a host via ssh, it will prompt you with the never-before-seen host key of that server. If the administrator of the server wanted to make sure you had a secure connection, they'd have shown you a copy of the fingerprint of the server already. If the fingerprint doesn't match, do not accept the connection to the server or attempt to continue. You could be compromising your remote account by going along with a man-in-the-middle attack.

If your server's administrator hadn't informed you of the server's host key already (and you don't know anyone else who already knows the server's host key), you're left with no choice but to cross your fingers the first time you connect to the host and hope there's no attack going on. After that, the key is stored in your ~/.ssh/known_hosts file, and your tools will check against it automatically.

why does server authentication matter?

Why does this matter? A communication session is only really secure if you know who is on the other end of the session. In a scattered global digital network, it's very difficult to tell who you're connecting to by non-cryptographic means. Consider making a phone call to your friend Alice who you want to tell a secret. If you were to just call Alice's phone number and then blurt out your secret, you would be telling anyone who picked up Alice's phone. You need to know that it's Alice before you even begin the communication in order to maintain a secure connection.

ssh-agent and friends

Public Key authentication is a very useful tool. But managing your private key successfully if you use SSH often can be frustrating. If you have ssh-agent installed, you can hand your keys off to the agent, and then each of your OpenSSH client programs know how to ask the agent to use your keys. The clients never actually see the keys: they just hand off the cryptographic challenge to the agent, which computes the response and sends it back. Reasonable people request the agent to prompt them for confirmation before computing and replying to a cryptographic challenge. This ensures that your agent won't use your keys without you knowing about it.

There are several other cryptographic agents under active development, some of which can perform ssh-agent-style functionality. Your system might be configured by default with something other than the standard ssh-agent, but it should be functionally equivalent.

using OpenSSH as a system component

The OpenSSH developers do not want to be library developers. This is understandable, given the headaches involved with library maintenance. They've been very careful to make sure that their toolset behaves in stable, standardized ways. So if you want to use OpenSSH tools in a system you're creating, you'll have better luck if you think about the OpenSSH portion of the system as its own individual processes, and consider how you can connect the other components of your system to stdin, stdout, and other sockets created by those processes.

This "please treat OpenSSH as an independent binary, not a library" model also has benefits when attempting to use the tool with other tools with different licenses. Many licenses (such as the GPL) restrict what sorts of libraries you can link with and retain your rights under the license. By using OpenSSH tools as separate programs, there is no linkages, and the consequences of the license do not trigger.

other free SSH implementations

  • PuTTY, an SSH client first developed for Microsoft Windows (though it works on POSIX-compliant systems as well)
  • lsh, a GPL'ed SSH implementation (server and client)
Last modified 9 years ago Last modified on May 23, 2008, 12:28:26 AM