Using SSL Keys

I recently updated my SSL keys. Several servers are accessed by keys from a few devices. A common authorized_hosts file was created as a template. This post covers the generation and use of SSL keys.

Generating Keys

The traditional key format is RSA, two forms should no longer be used. (Some older implementations may require the use of one of these forms.) There are two newer formats: ecdsa and ed25519. You may want to use one of these formats if your software supports them. The newer formats offer strong security with smaller keys. You can generate a new key in the default location using one of these commands:

ssh-keygen
ssh-keygen -t ecdsa 
ssh-keygen -t ed25519

The default private key names start with id_ and end with the key type. The public key should be password protected. The public key name is the same as the private key with a .pub suffix. These are stored in the .ssh subdirectory of the user’s home directory

On all my systems I deleted the existing keys. Then I generated new ecdsa keys. I then collected the public keys on one host.

Automating Connections

All the public keys were collected into a single file. The resulting file can be used as an authorized_keys file allowing all user host combinations to be accessed via the public keys.

Copies of this file were generated and edited to contain only the appropriate keys for particular user host combinations. For most hosts access to only a few users from a short list of hosts was allowed. These were then distributed to the targe .ssh directories on the desired hosts. Once key-based access is tested, it is possible to disable the ssh password mechanisms.

Restricting Password Access

Debian/Ubuntu includes files in /etc/ssh/sshd_conf.d in the sshd configuration, If your sshd configuration has an include directory, add the following lines to a file in the include directory. Otherwise, you can make the equivalent changes in the sshd_config file. (Note: KbdInteractiveAuthentication is likely already disabled.)

PasswordAuthentication no
KbdInteractiveAuthentication no

Keep a logged-in session open while testing this change.

• Restart the ssh server daemon.
• Open an ssh connection to the user@host. This should succeed using the key. If the key is password protected, the key’s password may be requested.
• Disable the authorized_keys file. (Move it to a different directory or name.)
• Open an ssh connection to the user@host. (This should fail as passwords are disabled and no key is available.
• Enable the authorized_keys file. (Move the file back.)
• Open an ssh connection to the user@host. This should succeed using the key.