SSH: From Secure Administration to Virtual Private Networking

Configuring the Server, Step 2: SSH User Config
Now that you have an SSH daemon running, you'll want to selectively allow users to connect. SSH supports host authentication using .shosts (a more secure version of .rhosts) or .rhosts plus RSA authentication. Either can be used to allow open-door access by trusted hosts. We decided to require user authentication and configured a security policy for each login granted SSH access.

With OpenSSH, configuration files and keys are located in each user's .ssh directory. To use public key user authentication, we start by invoking ssh-keygen to create an RSA key pair for SSH1 and a DSA key pair for SSH2. Unlike the host keys generated earlier, these keys identify this user. Next, we create a pair of authorization files (authorized_keys and authorized_keys2) containing all the public keys permitted access as this user.

Initially, we add our own public key to each authorization file, allowing local OpenSSH client "loopback" connections for testing. We'd do something similar to permit remote OpenSSH clients to connect to this server. For a third-party SSH client to connect, we need to convert the remote user's public key file before adding it to the authorization file. Those familiar with other SSH products will note that OpenSSH also uses different filenames and locations: .ssh instead of .ssh2, authorized_keys instead of authorization, no identification file, embedded keys instead of referenced public key files. The last item is the only deviation we'd quibble with: We find the authorization file format used by OpenSSH less manageable than the by-reference format used by non-commercial SSH 2.0.13.