Allow vault ssh to accept ssh commands in any ssh compatible format #4710
Conversation
|
This seems to revert #4673 which you yourself created (to use the hostname instead of IP) -- is that what you meant to do? |
|
@jefferai Yes. Before vault was replacing the original ssh command and setting it to be |
|
Let me add a few more examples in case that didn't clear things up. In the examples my hostname is Before #4673 After #4673 Now But also any form of username/port specification allowed by ssh also works as expected. The |
Crazybus
force-pushed
the
ssh_original_taste
branch
from
0536f88
to
942fd2d
Compare
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
When tested with the -race flag in travis it was properly catching that these arguments to Errorf had not been set properly. ``` command/ssh_test.go:143: Errorf format %q reads arg hashicorp#1, but call has only 0 args ```
Crazybus
force-pushed
the
ssh_original_taste
branch
from
125e917
to
59e0e7f
Compare
| @@ -460,10 +470,6 @@ func (c *SSHCommand) handleTypeCA(username, hostname, ip string, sshArgs []strin | |||
| ) | |||
| } | |||
|
|
|||
| args = append(args, | |||
There was a problem hiding this comment.
Why is this removed entirely? We don't need to pass in the username, IP, and port to the SSH command explicitly any more?
There was a problem hiding this comment.
Correct. My comment here should clear things up for you: #4710 (comment)
The current behaviour was to expect username@hostname as the first argument. This was then added to the actual ssh command with username@hostname plus the remaining ssh arguments. This PR removes that limitation of needing to use username@hostname and instead allows you to use any valid ssh command so that vault doesn't need to modify the actual command.
|
Thanks! |
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 beusername@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 compatibleusername@hostnameformatChanges
-panduser@if both options are specified.