SSH Keys
Last updated
Last updated
This is realized by
This is a standalone backend plugin for use with. This plugin allows for SSH public keys and SSH certificates to authenticate with Vault.
This is a and is meant to work with Vault. This guide assumes you have already installed Vault and have a basic understanding of how Vault works.
Otherwise, first read this guide on how to get started with Vault.
If you wish to work on this plugin, you'll first need installed on your machine.
Next, clone this repository into vault-plugin-auth-ssh
.
To compile a development version of this plugin, run make build
. This will put the plugin binary in the ./vault/plugins
folders.
Run make start
to start a development version of vault with this plugin.
Enable the auth plugin backend using the SSH auth plugin:
Look into the devsetup.sh
script, this will build the plugin, build certsig and setup a test environment with ssh-client signing, ssh certificate and public key test.
ssh_ca_public_keys
If you want to use ssh certificates you'll need to configure the ssh CA's which the certificates will validate against.
sshca in this example is a file containing your SSH CA. You can specify multiple CA's.
secure_nonce
If you disable secure_nonce
you can use timebased nonces. (this is a possible security risk)
You can create / list / delete roles which are used to link your certificate or public keys to Vault policies.
SSH certificate
Create a role with the policy ssh-policy
bound to a certificate with the principal ubuntu
.
(prerequisite: a SSH CA needs to be configured in auth/ssh/config)
SSH public keys
Create a role with the policy ssh-policy
bound to a specific publickey.
SSH public key self-registration
SSH certificate
For example
SSH public key
For example
Using templated policies
For example
will create the metadata keys "key1" and key2" with values "val1" and "val2", respectively.
You must get the nonce from vault read auth/ssh/nonce
For example:
With a pass
You may optionally set any of the which will be used as defaults if not overridden in a role.
By default the secure_nonce
config option is enabled. This means vault will generate a nonce for you with a lifetime of 30 seconds.
You can get this nonce by doing vault read auth/ssh/nonce
the resulting nonce must be used to create a signature over. (see )
You may optionally set any of the to override default values.
If your Vault has another authentication method that users can use, perhaps one that requires more user interaction such as , it is possible to use that other authentication method to securely enable users to register their own public keys for SSH authentication.
First, configure default standard token parameters for SSH authentication as above, so users do not have to choose them, especially the token_policies
parameter. Next, configure the other authentication method with a policy that enables writing public keys to the auth/ssh/role
path but doesn't allow other parameters. For example use a like this:
See about how to create those.
See about how to create those.
This plugin makes aliases available for use in Vault . These can be used to limit what secrets a policy makes available while sharing one policy between multiple roles. The defined role is always available in policies as {{identity.entity.aliases.<mount accessor>.name}}
. In addition, a login can add any metadata keys with values to further limit secrets paths via the metadata
parameter available as {{identity.entity.aliases.<mount accessor>.metadata.<metadata key>}}
. The metadata parameter is a mapping of keys to values which should be input as JSON, for example:
For now you can use the tool to generate your signature and nonce.
Signatures can also be created using ssh-agent. See the and for examples of how to do that.