Signed SSH Certificates using Hashicorp Vault in Practice
In previous setup, root token is used all the time, which should not be the case in real situation.
Steps
Preparation of Vault and SSH Server
The steps can follow Signed SSH Certificates using Hashicorp Vault
Using root token
export VAULT_TOKEN=<root_token>
export VAULT_ADDR='http://host:8200'
Create Policy
$ vault policy write my-policy - << EOF
path "ssh-client-signer/sign/my-role" {
capabilities = ["create", "update", "read"]
}
EOF
Get Policy token
$ vault token create -field token -policy=my-policy
Test Policy in SSH client machine
- Using token in SSH client
$ export VAULT_TOKEN="<policy_token>"
$ vault write -field=signed_key ssh-client-signer/sign/my-role public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pub
- SSH into target system using signed public key and private key in SSH client
ssh -i signed-cert.pub -i ~/.ssh/id_rsa ubuntu@host
Enable approle
vault auth enable approle
Create role
vault write auth/approle/role/my-role \
secret_id_ttl=10m \
token_num_uses=10 \
token_ttl=20m \
token_max_ttl=30m \
secret_id_num_uses=40 \
token_policies=my-policy
Get role_id and secret_id
vault read -field=role_id auth/approle/role/my-role/role-id
vault write -f -field=secret_id auth/approle/role/my-role/secret-id
Login from SSH client machine
export VAULT_ADDR='http://host:8200'
export ROLE_ID=<role_id>
export SECRET_ID=<secret_id>
vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"
Result contains token
Key Value
--- -----
token s.Sh9h1wZ9ycATeSaASoOQvovr
...
Check the token info
vault token lookup | grep policies
policies [default my-policy]
Test Policy in SSH client machine
- Using token in SSH client
$ export VAULT_TOKEN="<policy_token>"
$ vault write -field=signed_key ssh-client-signer/sign/my-role public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pub
- SSH into target system using signed public key and private key in SSH client
ssh -i signed-cert.pub -i ~/.ssh/id_rsa ubuntu@host
Consideration
Disable password authentication
If tested finished, password authentication can be set to no:
PasswordAuthentication no
Time valid for SECRET_ID
If the secret_id expires so fast, then needs to have master token to generate secret_id again, because the policy token is generated using role_id and secret_id pair.
If don't use approle, then all SSH clients can use policy token. Still thinking the advantage of using role_id and secret_id.
Use admin token instead
The root token should not be used as recommended. Will try admin token later.