@mitchellh suggested we fork `cli` and switch to that.
Since we primarily use the interfaces in `cli`, and the new
fork has not changed those, this is (mostly) a drop-in replacement.
A small fix will be necessary for Vault Enterprise, I believe.
* Adding explicit MPL license for sub-package.
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Adding explicit MPL license for sub-package.
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Updating the license from MPL to Business Source License.
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at www.hashicorp.com/licensing-faq, and details of the license at www.hashicorp.com/bsl.
* add missing license headers
* Update copyright file headers to BUS-1.1
* Fix test that expected exact offset on hcl file
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: Sarah Thompson <sthompson@hashicorp.com>
Co-authored-by: Brian Kassouf <bkassouf@hashicorp.com>
Append call in form of `append(s)` has no effect,
it just returns `s`. Sometimes such invocation is a sign
of a programming error, so it's better to remove these.
Signed-off-by: Iskander Sharipov <quasilyte@gmail.com>
Making this configurable is useful for windows users which may not be
using the default `ssh` executable. It also means that users can point to a
specify SSH executable if multiple are available.
* Allow vault ssh to accept ssh commands in any ssh compatible format
Previously vault ssh required ssh commands to be in the format
`username@hostname <flags> command`. While this works just fine for human
users this breaks a lot of automation workflows and is not compatible
with the options that the ssh client supports.
Motivation
We currently run ansible which uses vault ssh to connect to hosts.
Ansible generates ssh commands with the format `ssh <flags> -o User=username hostname
command`. While this is a valid ssh command it currently breaks with
vault because vault expects the format to be `username@hostname`. To work
around this we currently use a wrapper script to parse the correct username being set
by ansible and translate this into a vault ssh compatible `username@hostname` format
Changes
* You can now specify arguments in any order that ssh client allows. All
arguments are passed directly to the ssh command and the format isn't
modified in any way.
* The username and port are parsed from the specified ssh command. It
will accept all of the options supported by the ssh command and also
will properly prefer `-p` and `user@` if both options are specified.
* The ssh port is only added from the vault credentials if it hasn't
been specified on the command line
Don't set a default value for the UserKnownHostsFile flag.
Only append `-o UserKnownHostsFile` to the ssh command if it
has been specified by the user or vault ssh has set it based on another
flag (such as flagHostKeyMountPoint)
Fixes https://github.com/hashicorp/vault/issues/4672
This is implementing the same fix that was added for the CA mode for vault
ssh in https://github.com/hashicorp/vault/pull/3922
Using the IP address caused `Host` entries in the ssh_config to not
match anymore meaning you would need to hardcode all of your IP
addresses in your ssh config instead of using DNS to connect to hosts
* Use Colored UI if stdout is a tty
* Add format options to operator unseal
* Add format test on operator unseal
* Add -no-color output flag, and use BasicUi if no-color flag is provided
* Move seal status formatting logic to OutputSealStatus
* Apply no-color to warnings from DeprecatedCommands as well
* Add OutputWithFormat to support arbitrary data, add format option to auth list
* Add ability to output arbitrary list data on TableFormatter
* Clear up switch logic on format
* Add format option for list-related commands
* Add format option to rest of commands that returns a client API response
* Remove initOutputYAML and initOutputJSON, and use OutputWithFormat instead
* Remove outputAsYAML and outputAsJSON, and use OutputWithFormat instead
* Remove -no-color flag, use env var exclusively to toggle colored output
* Fix compile
* Remove -no-color flag in main.go
* Add missing FlagSetOutputFormat
* Fix generate-root/decode test
* Migrate init functions to main.go
* Add no-color flag back as hidden
* Handle non-supported data types for TableFormatter.OutputList
* Pull formatting much further up to remove the need to use c.flagFormat (#3950)
* Pull formatting much further up to remove the need to use c.flagFormat
Also remove OutputWithFormat as the logic can cause issues.
* Use const for env var
* Minor updates
* Remove unnecessary check
* Fix SSH output and some tests
* Fix tests
* Make race detector not run on generate root since it kills Travis these days
* Update docs
* Update docs
* Address review feedback
* Handle --format as well as -format
1. The current implementation of the SSH command is heavily tied to the
assumptions of OTP/dynamic key types. The SSH CA backend is
fundamentally a different approach to login and authentication. As a
result, there was some restructuring of existing methods to share more
code and state.
2. Each authentication method (ca, otp, dynamic) are now fully-contained
in their own handle* function.
3. -mode and -role are going to be required for SSH CA, and I don't
think the magical UX (and overhead) of guessing them is a good UX. It's
confusing as to which role and how Vault guesses. We can reduce 66% of
the API calls and add more declaration to the CLI by making -mode and
-role required. This commit adds warnings for that deprecation, but
these values are both required for CA type authentication.
4. The principal and extensions are currently fixed, and I personally
believe that's good enough for the first pass at this. Until we
understand what configuration options users will want, I think we should
ship with all the local extensions enabled. Users who don't want that
can generate the key themselves directly (current behavior) or submit
PRs to make the map of extensions customizable.
5. Host key checking for the CA backend is not currently implemented.
It's not strictly required at setup, so I need to think about whether it
belongs here.
This is not ready for merge, but it's ready for early review.
From the sshpass manpage:
> The -p option should be considered the least secure of all of sshpass's options. All system users can see the password in the command line with a simple "ps" command. Sshpass makes a minimal attempt to hide the password, but such attempts are doomed to create race conditions without actually solving the problem. Users of sshpass are encouraged to use one of the other password passing techniques, which are all more secure.
This PR changes the sshpass behavior to execute a subprocess with the
SSHPASS envvar (which is generally regarded as more secure) than using
the -p option.
* Normalize "X arguments expected" messages
* Use "Vault" when referring to the product and "vault" when referring to an instance of the product
* Various minor tweaks to improve readability and/or provide clarity
