An SSH Key is a two part (public and private key) cryptographic token which is primarily used to facilitate remote secure shell (SSH) access to a computer.
In practice SSH Keys are used to sign in to servers, authenticate to remote repositories like Github, and as a way of verifying the authenticity of files and messages.
Engineers and other technical users need to semi-frequently generate new SSH keys to authenticate to various services. To do that they often generate the SSH key pair via the terminal by running the following command:
$ ssh-keygen -t ed25519 -C "email@example.com"
During the process they will eventually be asked to set a passphrase with a prompt that looks like the following:
> Enter passphrase (empty for no passphrase): [Type a passphrase]
Unfortunately, this portion of the process can be easily skipped by simply pressing the enter key on the keyboard. If this portion of the process is skipped the private key can be used by anyone who can get possession of the file.
Why do developers skip this step? There are a few reasons that come up in practice:
Ignorance - Many developers don’t know there is any security value in adding a passphrase to an SSH key.
Perceived Lack of Necessity - Many SSH keys are generated under the assumption they won’t be used to obtain access to anything important and thus adding a passphrase is unnecessary overkill.
Convenience - By adding a passphrase, developers often assume they will need to constantly enter a passphrase every time they push code to GitHub or access a commonly used server. By forgoing the password they don’t have to contend with any productivity loss.
While these arguments drive the behavior, none of them are strong. In fact, a lot of the perceived downsides of using an encrypted key can be mitigated with modern tools.
For example, on macOS if an encrypted SSH key is accessed by a process, you will be automatically prompted to enter the passphrase and then you can choose to save it in the keychain.
Osquery (an open-source tool for querying the state of the OS) is capable of
locating user SSH keys across devices. It does this by tapping into the
ssh-agent on the device and looking for them in common locations on the primary
Osquery uses SQL to query the system’s current state. Here is an example of a SQL query that can detect all unencrypted SSH keys on disk.
SELECT path FROM user_ssh_keys WHERE encrypted = 0;
Kolide extends osquery’s functionality with additional data like MD5 fingerprint and automatically stores metadata about keys in its built-in Inventory. This allows you to detect things like duplicate SSH keys across devices.
Encrypting a pre-existing SSH key is a trivial process. On Mac or Linux simply:
- Make note of the private SSH key you wish to encrypt. For this example, let’s assume it’s in
- Open the terminal
ssh-keygen -p -f /Users/user/.ssh/id_rsaand press enter
You will be prompted to create a passphrase. We suggest you create a unique passphrase per key and store those passphrases in a secure/approved password manager like 1Password.
You may not see text being entered as you type your password in. Do not worry, this is normal security feature of the terminal and it is receiving your keystrokes.
This problem cannot be remediated through traditional automation with tools like an MDM. You need to be able to stop devices that fail this check form authenticating to your SaaS apps and then give end-users precise instructions on how to unblock their device.
Kolide's Okta Integration does exactly that. Onece integrated in your sign-in flow, Kolide will automatically associate devices with your users' Okta identities. From there, it can block any device that exhibits this problem and then provide the user, step-by-step instructions on how to fix it. Once fixed, Kolide immediately unblocks their device. Watch a demo to find out more.