A Quick Guide To Set Up HashiCorp Vault’s SSH Secrets Engine

HarshiCorp vaults are commonly called HVault. It is a tool for storing, securing, and controlling access to certificates, passwords, tokens, and other secret data. Certificates of Vault provide a fairly seamless workflow leveraging them as SSH authentication method. Below is a guide to setup Vault deployment, and a walkthrough of server-side and client-side workflow for SSH.

How does it work?

If an end-user wants to SSH to a remote machine, they need to authenticate the vault. Once the ACL access is given to SSH secret engine role, the public key must be submitted to the vault for signing. After authorization, a subsequent new signed CA public key is returned. The user can use this key to SSH into remote servers. The returned CA can be given a TTL (time to live) to limit the time box window. This limitation is enforced by OpenSSH.

Installation

Step 1: Download the HarshiCorp vault binary package compiled from go language 64 bit Linux assured.

$ VAULT_VERSION=”1.3.1”

Defining the version into the variable to download the particular version of the package

$ curl -LO

https://releases.hashicorp.com/vault/${VAULT_VERSION}/vault_${VAULT_VERSION}_linux_amd64.zip

The above curl command is used to download the package file with a particular version

Step 2: Now that we’ve got the archive containing the Vault binary, we’ll unzip it and place the binary someplace convenient:

$ unzip -q vault_${VAULT_VERSION}_linux_amd64.zip

The above command is used to unzip the downloaded file

$ sudo cp vault /usr/local/bin/

Then copy the unzipped file into the bin folder.

Configure Vault systemd service

After installing the vault, let’s configure systemd service to manage run as a service. Start by creating a unique, non-privileged system user to run Vault.

Create Vault data directories.

$ sudo mkdir /etc/vault
$ sudo mkdir -p /var/lib/vault/data

Then create user named vault.

$ sudo useradd — system — home /etc/vault — shell /bin/false vault
$ sudo chown -R vault:vault /etc/vault /var/lib/vault/

Create a Vault service file at /etc/systemd/system/vault.service

$ touch /etc/systemd/system/vault.service
$ cat <<EOF | sudo tee /etc/systemd/system/vault.service
[Unit]
Description=”HashiCorp Vault — A tool for managing secrets”
Documentation=https://www.vaultproject.io/docs/
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/etc/vault/config.hcl
[Service]
User=vault
Group=vault
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
AmbientCapabilities=CAP_IPC_LOCK
NoNewPrivileges=yes
ExecStart=/usr/local/bin/vault server -config=/etc/vault/config.hcl
ExecReload=/bin/kill — signal HUP
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
StartLimitBurst=3
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
EOF

Then create vault /etc/vault/cofig.hcl file

$ touch /etc/vault/config.hcl

Add basic configuration settings for Vault to /etc/vault/config.hcl file.

$ cat <<EOF | sudo tee /etc/vault/config.hcl
disable_cache = true
disable_mlock = true
ui = true
listener “tcp” {
address = “0.0.0.0:8200”
tls_disable = 1
}
storage “file” {
path = “/var/lib/vault/data”
}
api_addr = “http://0.0.0.0:8200”
max_lease_ttl = “10h”
default_lease_ttl = “10h”
cluster_name = “vault”
raw_storage_endpoint = true
disable_sealwrap = true
disable_printable_check = true
EOF

Start and enable vault service to start on system boot.

$ sudo systemctl daemon-reload
$ sudo systemctl enable — now vault
To check service status
$ systemctl status vault

Initialize Vault Server

Before initializing and unsealing, we need to make sure that the Vault client can find the running server.

$ export VAULT_ADDR=”http://127.0.0.1:8200"

Make sure this gets picked up in new shells:

$ echo ‘export VAULT_ADDR=”http://127.0.0.1:8200"' >> ~/.bashrc

Next, we initialize Vault:

$ vault operator init -key-shares=1 -key-threshold=1

NOTE: In production, you’ll want to increase the key shares (number of keys that may unseal Vault) and the key threshold (number of keys required to unseal Vault).

Unseal

Vault is ready to be unsealed using the unseal key we just received:

$ vault operator unseal <Unseal key>

Now, login with the given root token

Auditing

There are inbuilt auditing features in the vault for recording the activities that are done by log.

To enable the auditing

$ vault audit enable syslog

SSH Engine

To make use of the SSH Secrets Engine, we must first enable it:

$ vault secrets enable -path=ssh-client ssh

Then, configure a Certificate Authority for signing the client certificates. We’ll redirect the public key output to a file which eventually needs to be distributed to hosts we wish on SSH, using client certificates:

$ vault write \
-field=public_key \
ssh-client/config/ca \
generate_signing_key=true \
| sudo tee /etc/ssh/trusted-user-ca-keys.pem

We then configure the SSH daemon to use our new CA certificate:

$ echo “TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem” | sudo tee -a /etc/ssh/sshd_config
$ sudo sshd -t #
$ sudo systemctl reload sshd

Roles

Roles in Vault are created by writing data to special paths. Roles provide a fine-grained interface for constraining the details that go into a signed client certificate.

Roles are used to restrict access to a subset of machines.

$ cat > regular-user-role.hcl <<EOF
{
“allow_user_certificates”: true,
“allowed_users”: “centos,ec2-user,ubuntu”,
“default_user”: “ec2-user”,
“allow_user_key_ids”: “true”,
“default_extensions”: [
{
“permit-pty”: “”
}
],
“key_type”: “ca”,
“ttl”: “8h”,
“allow_user_key_ids”: “false”,
“key_id_format”: “{{token_display_name}}”
}
EOF

Now we write the role to Vault:

$ cat regular-user-role.hcl | vault write ssh-client/roles/regular –

We care about our users, we’ve made the process easy on them. When users need to SSH they hit the ssh-client/sign/regular path.

Policies

Policies allow us to define which users can request certificates from (i.e. write data to) certain paths. Not all users should be able to request a certificate that would allow them to SSH.

First we create a policy for regular users:

$ cat > regular-user-role-policy.hcl <<EOF
path “ssh-client/sign/regular” {
capabilities = [“create”,”update”]
}
EOF

When we’re satisfied with the policies, we can write them to Vault:

$ vault policy write ssh-regular-user regular-user-role-policy.hcl

Client Workflow

We start by enabling the userpass authentication method:

$ vault auth enable -path=plain userpass

This authentication method is a basic username and password authentication mechanism.

Next, we create some users in Vault:

$ vault write auth/plain/users/<username> \
password=”<Password>” \
policies=”ssh-regular-user”

Now, we’re ready for client-side workflow.

The very first step is to generate an RSA key pair if you don’t already have one:

$ ssh-keygen -qf $HOME/.ssh/id_rsa -t rsa -N “”

Now we need to create scripts for the client to authenticate (vault_connect) and make ssh connection (act_connect), by a simple command.

First, we create a script for the user to access the vault by using a username and password and request the CA certificate

$ touch vault_connect.sh

Then enter the following codes in the script

while getopts u:p: flag
do
case “${flag}” in
u) username=${OPTARG};;
p) password=${OPTARG};;
esac
done
vault login -path=plain -method=userpass username=$username password=$password
vault write \
-field=signed_key \
ssh-client/sign/regular \
valid_principals=”ec2-user” \
public_key=@$HOME/.ssh/id_rsa.pub \
> $HOME/.ssh/cert-signed.pub

Now create another script for making ssh connection

$ touch act_connect.sh

Now enter the following codes in the act_connect.sh script

while getopts ip: flag
do
case “${flag}” in
p) ip_add=${OPTARG};;
esac
done
ssh -i $HOME/.ssh/id_rsa -i $HOME/.ssh/cert-signed.pub ec2-user@$ip_add

Now we need to move the scripts to the /usr/local/bin folder to access all the users.

Now user can log in and request the CA certificate by using the following command

$ sh vault_connect.sh –u <username> -p <password>

After receiving the CA file we can check the key using the below command:

Ssh-keygen -Lf $HOME/.ssh/cert-signed.pub

The CA key with details is shown below.

This user can now make the ssh to the hosted machine

$ sh act_connect.sh ip <ip address of host machine>

FOR MULTIPLE USERS

Add users in Linux machine using useradd command.

Then generate id_rsa key for that user using :

ssh-keygen -qf $HOME/.ssh/id_rsa -t rsa -N “”

Then export the address

export VAULT_ADDR=http://127.0.0.1:8200
echo ‘export VAULT_ADDR=”http://127.0.0.1:8200"' >> ~/.bashrc

Conclusion:

This is only a tiny introduction to HashiCorp Vault, there is a lot more to explore, but I guess at least it’s clear how to interact with it and do basic operations.

Ankercloud has helped several companies rapidly adopt Vault in a wide range of computing platforms from architecture design, all the way down to monitoring. If you are looking for a partner who can help you with advanced options. Please write to us at info@ankercloud.com with details and we will get in touch with you.

Reference

https://abridge2devnull.com/posts/2018/05/leveraging-hashicorp-vaults-ssh-secrets-engine/

https://computingforgeeks.com/install-and-configure-vault-server-linux/