Take Away the Keys!

Simplifying SSH Authentication for Users

by J. Edward Durrett

If you want a group of people to lose complete interest in what you are saying, just start talking about public and private
key pairs related to SSH authentication. There will be a few who do take interest, only to get lost in confusion about where
the public key goes and where the private key stays. As evidence of this, it is not uncommon for key pairs (yes both of
them - the public and private) to be uploaded to web roots, github, virus total, etc [1] [2]. In fact, a majority of business
have no knowledge of and no control over what their developers are doing with their SSH key pairs [3]. It seems, from experience,
most people are given an outline of what they are supposed to do, maybe a link to a web site with an explanation, and then
turned lose to sprinkle their login credentials all over the Internet. Luckily, there is one simple solution to this problem,
one that keeps existing SSH infrastructure (it is after all both secure and convenient) and also allows company to manage the
keys for the developers that use them. The solution is SSH certificate authentication.

Like other certificate authentication schemes, a CA (Certificate Authority) is needed. The CA holds the the CA certificate
used to sign the public certificate of users. The public key of the CA is put on host users authenticate to. So for example, a
web server. The CA can then use its private key to sign a certificate, specifying the user and time validity, for the client,
let's say a developer, to authenticate to the host, the web server. The example below, which goes through the steps of
using SSH certificate authentication, will clarify this explanation:

First, create the CA cert key pair:

ssh-keygen -b 4096 -t rsa -f /path/to/certs/CA_CERT

Then, modify the sshd_config file on the host where authentication is going to occur, ie the web server, to allow certificate

TrustedUserCAKeys /path/to/public_key/CA_CERT.pub

Of course, the public key created in the first step needs to be put on the host at the path specified in the sshd_config file.
Now, on the CA, using the CA private key, an authentication certificate can be created:

ssh-keygen -s CA_CERT -I SIGNED_KEY -n someuser -V +120s USER_KEY.pub

This creates a key a user, named someuser, can use to authenticate for 120 seconds. That does not mean the session can last
only 120 seconds, only that the user can only authenticate in that 120second window. If a user is not specified, any valid
user can use you the certificate. Of course, to implement a solution based on this type of authentication, please carefully
read the manual to ensure new holes are not opened as one is closed.

[1] https://www.sans.org/newsletters/newsbites/xix/83#300
[2] https://www.bleepingcomputer.com/news/security/attackers-start-scans-for-ssh-keys-after-report-on-lack-of-ssh-security-controls/
[3] http://www.businesswire.com/news/home/20171017005080/en/Study-61-Percent-Organizations-Minimal-Control-SSH

Copyright (c) 2019, Jason Edward Durrett - All content on this site, unless otherwise noted, is subject to this license.

Please contact me if any errors, such as erroneous / misleading content or missing / incomplete attribution, are found.