AllGoodBits.org

Getting Started with ssh keys

One of the first steps on the path to security is making it easy for permitted individuals to login and all others are rejected. There are many online and offline discussions of how to do this, the merits and flaws of each method. This article will demonstrate the methods that I recommend for using OpenSSH for granting or denying login to remote unixlike systems. OpenSSH is a suite of tools from the OpenBSD project which is the overwhelmingly toolset for secure network communications.

The basic idea is to create a public key which you can give to anyone who wants to grant you access to their system and a private key which you clutch tight and never reveal to anyone. Then you need to get that public key to where the server, sshd(8), can use it. These next two sections on generating and placing ssh keys assume that your environment and tools use the defaults as provided by many current linux and unixlike systems. Then I'll demonstrate the convenience of ssh-agent.

In this article, the hostname 'here' refers to the originating, local system and the hostname 'there' refers to the remote system, to which we are granting access.

Other keys can be added to ssh-agent similarly. Keys can be deleted with ssh-add -D.

Agent Forwarding

When I'm using ssh keys to access a machine that I control, I might enable Agent Forwarding, which enables a tunnel from the remote machine back to the original so that the agent is available to enable me to reach further machines. Because of the security implications of this, I don't automatically do this by default:

ssh -A there.allgoodbits.com

Extra SSH happiness

Multiplexing

When I'm using ssh to connect to a server from multiple sessions or to the
same server repeatedly, then I use the multiplex functionality. This allows each subsequent session to use the same TCP connection to the server, which makes login on subsequent sessions faster. There is a minor side-effect of reducing the chance that the original session will timeout in the event that it idles for a while because my focus is elsewhere.

In ~/.ssh/config:

Host *
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

SSH SOCKS Proxy

On a untrusted network (which is almost everything, really, no?), it might be
nice to send all HTTP traffic over an SSH connection to a trusted destination
(that I control), and then on to the destination from there.

This is easy. Just ssh to the trusted destination with Dynamic
Forwarding:

ssh -D <pick a highnumbered port> myfaveserver.example.com

Then tell the browser to use the port that specified above as the SOCKS proxy.
In current Mozilla Firefox, for example, that configuration lives under
Advanced>Network>Settings, entering localhost as the SOCKS host and the
port specified.

In about:config, set network.proxy.socks_remote_dns = true and Firefox
will send DNS requests over the secure proxy as well, so those will not be
available to be seen on the local network.