Deprecated: There are several serious drawbacks and security implications
inherent in this type. Because of these drawbacks, please use the SSH CA or OTP
types whenever possible.
When using this type, the administrator registers a secret key with appropriate
sudo privileges on the remote machines; for every authorized credential
request, Vault creates a new SSH key pair and appends the newly-generated public
key to the authorized_keys file for the configured username on the remote
host. Vault uses a configurable install script to achieve this.
The secrets engine does not prompt for sudo passwords; the NOPASSWD option for
sudoers should be enabled at all remote hosts for the Vault administrative
user.
The private key returned to the user will be leased and can be renewed if
desired. Once the key is given to the user, Vault will not know when it gets
used or how many time it gets used. Therefore, Vault WILL NOT and cannot
audit the SSH session establishments.
When the credential lease expires, Vault removes the secret key from the remote
machine.
This page will show a quick start for this secrets engine. For detailed documentation
on every path, use vault path-help after mounting the secrets engine.
The dynamic key type has several serious drawbacks:
Audit logs are unreliable: Vault can only log when users request
credentials, not when they use the given keys. If user A and user B both
request access to a machine, and are given a lease valid for five minutes,
it is impossible to know whether two accesses to that user account on the
remote machine were A, A; A, B; B, A; or B, B.
Generating dynamic keys consumes entropy: Unless equipped with a hardware
entropy generating device, a machine can quickly run out of entropy when
generating SSH keys. This will cause further requests for various Vault
operations to stall until more entropy is available, which could take a
significant amount of time, after which the next request for a new SSH key
will use the generated entropy and cause stalling again.
This type makes connections to client hosts; when this happens the host key
is not verified.
In order to adjust the authorized_keys file for the desired user, Vault
connects via SSH to the remote machine as a separate user, and uses sudo to
gain the privileges required. An example sudoers file is shown below.
File: /etc/sudoers
# This is a sample sudoers statement; you should modify it# as appropriate to satisfy your security needs.
vaultadmin ALL=(ALL)NOPASSWD: ALL
# This is a sample sudoers statement; you should modify it# as appropriate to satisfy your security needs.vaultadmin ALL=(ALL)NOPASSWD: ALL
Next, create a role. All of the machines contained within this CIDR block list
should be accessible using the registered shared secret key.
$vault write ssh/roles/dynamic_key_role \ key_type=dynamic \ key=dev_key \ admin_user=username \ default_user=username \ cidr_list=x.x.x.x/ySuccess! Data written to: ssh/roles/dynamic_key_role
$vault write ssh/roles/dynamic_key_role \ key_type=dynamic \ key=dev_key \ admin_user=username \ default_user=username \ cidr_list=x.x.x.x/ySuccess! Data written to: ssh/roles/dynamic_key_role
cidr_list is a comma separated list of CIDR blocks for which a role can
generate credentials. If this is empty, the role can only generate credentials
if it belongs to the set of zero-address roles.
Zero-address roles, configured via /ssh/config/zeroaddress endpoint, takes
comma separated list of role names that can generate credentials for any IP
address.
Use the install_script option to provide an install script if the remote
hosts do not resemble a typical Linux machine. The default script is compiled
into the Vault binary, but it is straight forward to specify an alternate. The
script takes three arguments which are explained in the comments.
