mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-18 12:37:02 +02:00
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
109 lines
3.8 KiB
Markdown
109 lines
3.8 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "ssh - Command"
|
|
sidebar_title: "ssh"
|
|
sidebar_current: "docs-commands-ssh"
|
|
description: |-
|
|
The "ssh" command establishes an SSH connection with the target machine using
|
|
credentials obtained from an SSH secrets engine.
|
|
---
|
|
|
|
# ssh
|
|
|
|
The `ssh` command establishes an SSH connection with the target machine.
|
|
|
|
This command uses one of the SSH secrets engines to authenticate and
|
|
automatically establish an SSH connection to a host. This operation requires
|
|
that the SSH secrets engine is mounted and configured.
|
|
|
|
The user must have `ssh` installed locally - this command will exec out to it
|
|
with the proper commands to provide an "SSH-like" consistent experience.
|
|
|
|
## Examples
|
|
|
|
SSH using the OTP mode (requires [sshpass](https://linux.die.net/man/1/sshpass)
|
|
for full automation):
|
|
|
|
```text
|
|
$ vault ssh -mode=otp -role=my-role user@1.2.3.4
|
|
```
|
|
|
|
SSH using the CA mode:
|
|
|
|
```text
|
|
$ vault ssh -mode=ca -role=my-role user@1.2.3.4
|
|
```
|
|
|
|
SSH using CA mode with host key verification:
|
|
|
|
```text
|
|
$ vault ssh \
|
|
-mode=ca \
|
|
-role=my-role \
|
|
-host-key-mount-point=host-signer \
|
|
-host-key-hostnames=example.com \
|
|
user@example.com
|
|
```
|
|
|
|
For step-by-step guides and instructions for each of the available SSH
|
|
auth methods, please see the corresponding [SSH secrets
|
|
engine](/docs/secrets/ssh/index.html).
|
|
|
|
## Usage
|
|
|
|
The following flags are available in addition to the [standard set of
|
|
flags](/docs/commands/index.html) included on all commands.
|
|
|
|
### Output Options
|
|
|
|
- `-field` `(string: "")` - Print only the field with the given name. Specifying
|
|
this option will take precedence over other formatting directives. The result
|
|
will not have a trailing newline making it ideal for piping to other processes.
|
|
|
|
- `-format` `(string: "table")` - Print the output in the given format. Valid
|
|
formats are "table", "json", or "yaml". This can also be specified via the
|
|
`VAULT_FORMAT` environment variable.
|
|
|
|
### SSH Options
|
|
|
|
- `-mode` `(string: "")` - Name of the authentication mode (ca, dynamic, otp)."
|
|
|
|
- `-mount-point` `(string: "ssh/")` - Mount point to the SSH secrets engine.
|
|
|
|
- `-no-exec` `(bool: false)` - Print the generated credentials, but do not
|
|
establish a connection.
|
|
|
|
- `-role` `(string: "")` - Name of the role to use to generate the key.
|
|
|
|
- `-strict-host-key-checking` `(string: "")` - Value to use for the SSH
|
|
configuration option "StrictHostKeyChecking". The default is ask. This can
|
|
also be specified via the `VAULT_SSH_STRICT_HOST_KEY_CHECKING` environment
|
|
variable.
|
|
|
|
- `-user-known-hosts-file` `(string: "~/.ssh/known_hosts")` - Value to use for
|
|
the SSH configuration option "UserKnownHostsFile". This can also be specified
|
|
via the `VAULT_SSH_USER_KNOWN_HOSTS_FILE` environment variable.
|
|
|
|
### CA Mode Options
|
|
|
|
- `-host-key-hostnames` `(string: "*")` - List of hostnames to delegate for the
|
|
CA. The default value allows all domains and IPs. This is specified as a
|
|
comma-separated list of values. This can also be specified via the
|
|
`VAULT_SSH_HOST_KEY_HOSTNAMES` environment variable.
|
|
|
|
- `-host-key-mount-point` `(string: "")` - Mount point to the SSH
|
|
secrets engine where host keys are signed. When given a value, Vault will
|
|
generate a custom "known_hosts" file with delegation to the CA at the provided
|
|
mount point to verify the SSH connection's host keys against the provided CA.
|
|
By default, host keys are validated against the user's local "known_hosts"
|
|
file. This flag forces strict key host checking and ignores a custom user
|
|
known hosts file. This can also be specified via the
|
|
`VAULT_SSH_HOST_KEY_MOUNT_POINT` environment variable.
|
|
|
|
- `-private-key-path` `(string: "~/.ssh/id_rsa")` - Path to the SSH private key
|
|
to use for authentication. This must be the corresponding private key to
|
|
`-public-key-path`.
|
|
|
|
- `-public-key-path` `(string: "~/.ssh/id_rsa.pub")` - Path to the SSH public
|
|
key to send to Vault for signing.
|