How to Implement HashiCorp Vault SSH Secrets Engine for securing SSH access

Introduction

Many companies still used traditional username and password auth to connect our remote servers. Using passwords, no matter how complex it is, are vulnurable to various forms of attack, such as brute-force attempts or simply forgotten. In modern infrastructure, SSH is widely used for managing servers remotely. Unlike password-based authentication, SSH uses cryptographic keys to establish a secure connection, which offers a much higher level of security. As more SSH keys are generated and distributed accross different systems and users, it becomes increase and difficult to keep track of them all (key sprawl). There’s also the risk of unauthorized access, granting access to critical systems without detection, especially when former employees retain access they should no longer have. In this article, I’m going to walk through setting up how to implement HashiCorp Vault SSH Secrets Engine for securing SSH access.

1. Administrator authenticates to vault, enables SSH secrets engine, and generates a public key.
2. Administrator adds public key from vault to remote servers.
3. User sends the public key to an administrator for signing.
4. An administrator creates a certificate using the user’s public key.
5. The administrator sends the signed certificate to the user.
6. User using private key and signed certificate to connect to remote servers.

Prerequisite

Install Vault

You can read and follow these docs.

Setup SSH secrets engine

Enable SSH Secrets Engine

# dont forget to export your token by run this command 
export VAULT_TOKEN="<your token>"
vault secrets enable -path=ssh-creds ssh

Or if you are using UI, you can go through secrets engines tab → click enable new engines → click ssh → fill path with ssh-creds.

Configure Vault with CA

Configure Vault with a CA for signing client keys using the /config/ca endpoint. If you do not have an internal CA, Vault can generate a keypair for you.

vault write ssh-creds/config/ca generate_signing_key=true

If you already have a keypair, specify the public and private key parts as part of the payload.

vault write ssh-creds/config/ca \
    private_key="..." \
    public_key="..."

Or if you are using UI, on secrets engines tab, you can click ssh-creds → go to configuration tab → click configure → fill with your public and private key, or you can leave blank.

Get public key and save it

vault read -field=public_key ssh-creds/config/ca > trusted-user-ca-keys.pem

Add the public key to all target host's SSH configuration

Copy trusted-user-ca-keys.pem to /etc/ssh directory in remote server
Add the path where the public key contents are stored to the SSH configuration file as the TrustedUserCAKeys option.
Go to /etc/ssh/sshd_config and then add this.

TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem

This process can be manual or automated using a configuration management tool such as Ansible.

Create roles

Let's say we need to give access to developers, so we need to create a role for developers.
You can run this command.

vault write ssh-creds/roles/developers -<<"EOH"
{
  "algorithm_signer": "rsa-sha2-256",
  "allow_user_certificates": true,
  "allowed_users": "*",
  "allowed_extensions": "permit-pty,permit-port-forwarding",
  "default_extensions": {
    "permit-pty": ""
  },
  "key_type": "ca",
  "default_user": "ubuntu",
  "ttl": "10m0s" 
}
EOH

• “algorithm_signer” : "rsa-sha2-256" is a signing algorithm for the key.
• "allow_user_certificates": true is allowed to be signed for us as user.
• "allowed_users": "*" is list of vault user who are allowed to use this key, "*" means allow all the vault users.
• "allowed_extensions": "permit-pty,permit-port-forwarding" for permit-pty is necessary for allowing interactive SSH sessions, where users need to interact directly with the server’s shell. permit-port-forwarding is used to enable secure tunneling of ports, allowing users to access remote services securely through SSH.
• "default_extensions" with "permit-pty": "" are included for clarity, consistency, and to ensure that role behavior is explicitly defined.
• "key_type": "ca" is the type of key used to log in to hosts. It can be either “OTP” or “ca”. In this example, using ca.
• "default_user": "ubuntu" is the default host username when one isn’t specified.
• "ttl": "10m0s" is where certificate expiry is set when signing an SSH key, in this example 10 minutes.

If you are using UI, on secrets engines tab, you can click ssh-creds → on roles tab, click create role → fill role name with developers → checklist allow user certificate → fill default username, with ubuntu → fill allowed user with * → select ttl and then fill with 10 minutes → fill allowed extensions with permit-pty,permit-port-forwarding → fill default extensions with "permit-pty": "" → select signing algorithm with rsa-sha2-256.

Sign Public Key

Ask Vault to sign developer's public key. This file usually ends in .pub and the contents begin with ssh-rsa ....

vault write ssh-creds/sign/developers \
    public_key=<developer's public key> > signed-cert.pub

If you are using UI, on secrets engines tab, click ssh-creds → on roles tabs, click developers → paste public key, then save.

SSH into the host machine using the signed key. You must supply both the signed public key from Vault and the corresponding private key as authentication to the SSH call.

ssh -i signed-cert.pub -i <developer's private key> ubuntu@<ip host>

References

https://support.cloudways.com/en/articles/5120579-why-should-you-set-up-ssh-keys
https://developer.hashicorp.com/vault/docs/install
https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates