Security Best Practices

Contents

  1. About Passwords and Keypairs
  2. A note on using sudo authentication
  3. More Security Suggestions
    1. Use a Unique Keypair for Each SSH Server
    2. Never Upload Your Existing SSH Keys
    3. Don't use the root user via Shellvault
    4. Enable Shellvault Two-Factor Authentication (2FA)
    5. Safeguard SSH Access with Server-Side 2FA or a Keypair Password

This page describes ways you can maximize your account security in the event of a stolen account or database leak. We take security very seriously on our end, and we'd like to help you make good security choices too.

Have security-specific questions? Check out the FAQ or email us at help@shellvault.io.

About Passwords and Keypairs

SSH allows you to log in to a remote server with a username and password, but you can also use SSH keys for security and convenience. Shellvault uses SSH keys exclusively.

Keys are more secure than a password, and a key can be revoked if you want to block the key's owner's connections. An authorized keypair has two parts:

  • The public key, stored in your server's ~/.ssh/authorized_keys file (often copied there by ssh-copy-id).
  • The private key, stored where the local SSH process can read it. You should keep your private keys safe: don't share them with anyone!

Since the two keys are cryptographically coupled, the SSH process and server can perform a secure handshake (an algorithm involving the two large numbers the keys represent) to find out if your private key pairs with an authorized public key on the server and allow the connection accordingly.

To illustrate one of the benefits, if you use Shellvault to administer your sever but then decide to stop, you can revoke Shellvault's keys so that Shellvault can never access the server again, all without revealing your password. See the Shellvault FAQ for more.

Why does Shellvault support keys for authentication, but not passwords? Password storage is a heavy security burden. Just like we don't store credit card data on our servers, we don't want to store sensitive data that could be tied to your other accounts. Keys are simple to make, and you can easily create one specifically for your Shellvault account (you don't have to use the keys you already use at home).

Even so, if you prefer, you may temporarily give Shellvault your server password. We'll set up the key for you so you can get started without leaving Shellvault. Otherwise, you'll have to set authorize your Shellvault keys yourself. We don't store or log your password, but we still advise that you build good security habits by not sharing your passwords. We walk you through both methods in the Getting Started page.

A note on using sudo authentication

By default, Shellvault reminds you to be careful with your sudo user password whenever you're prompted for it. The suggestions below can help boost the security on your server so that a misuse of sudo (or a security leak) won't expose your machine to attackers.

More Security Suggestions

For maximum security, consider these suggestions, further detailed below:

  • Use 2-factor authentication (2FA) to log in to Shellvault
  • Create a new Shellvault keypair for every server.
  • Don't upload your existing private key to Shellvault.
  • Don't use Shellvault for root access
  • Use 2-factor SSH authentication on your server to block MITM attacks
  • Set up each key outside of Shellvault without giving us your password.

Use a Unique Keypair for Each SSH Server

It's simple to create a new keypair in Shellvault to use for each SSH server you use. For maximum security, consider creating a unique key to use with each of your connections. In the unlikely event of a single-key database breach, only one of your servers would be potentially compromised.

Never Upload Your Existing SSH Keys

Although we take every measure we can to secure your information, please do not upload SSH keypairs that you use to Shellvault: the risk and liability is too great, as a database breach could result in all of the places you use your SSH key to be compromised.

Don't use the root user via Shellvault

Some servers will give you access to the all-powerful root user. You can keep building your good security habits by not using Shellvault to control the root user, as anyone who successfully attacked Shellvault could get control of your entire server. Instead, follow good administrator practices and make another user that can use sudo for administrative tasks. Read more here.

Enable Shellvault Two-Factor Authentication (2FA)

After you make an account, it's easy to set up 2FA so that only you can log in to your Shellvault account. Go to your account settings page to get started.

Safeguard SSH Access with Server-Side 2FA or a Keypair Password

Shellvault 2FA can help protect your Shellvault account from attackers, but your SSH connections are still in danger if Shellvault is somehow compromised.

The best way to safeguard your SSH server is to configure server-side 2FA, which will prompt you upon login for a time-based security code. This kind of 2FA is entirely out of Shellvault's control, so your connections will be safe in the unlikely event that an attacker gains production-level permissions on our servers. See this DigitalOcean tutorial for Ubuntu 16.04 to get started.

You may also generate your own SSH key with ssh-keygen on a local device and set a password on it. Each time you use the key in Shellvault, you'll have to enter the password. This is less secure than the 2FA method described above, but is still a great way to add more security to your account (at the cost of slightly less convenience).