Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vault ssh shouldn't overwrite the users own configuration #4672

Closed
Crazybus opened this issue Jun 1, 2018 · 0 comments
Closed

Vault ssh shouldn't overwrite the users own configuration #4672

Crazybus opened this issue Jun 1, 2018 · 0 comments

Comments

@Crazybus
Copy link
Contributor

Crazybus commented Jun 1, 2018

Describe the bug
When using vault ssh certain command line flags such as -o UserKnownHostsFile are always appended to the ssh command and are not optional.

"-o UserKnownHostsFile=" + userKnownHostsFile,

The problem with this is that it takes precedence over the value that has been set per host in the users ssh config.

Host *
  UserKnownHostsFile .known_hosts

For this particular command line flag it is possible to specify it with the vault flag -user-known-hosts-file=.known_hosts. However this needs to be hardcoded in the vault ssh command and won't work for user cases where you have separate known_hosts files per host/group. Our usecase is that we are using vault ssh with ansible and maintain a .known_hosts file that is checked into git.

To Reproduce
Steps to reproduce the behavior:

  1. Create an ssh_config that specifies a non-default known_hosts location
Hostname 192.168.0.2
  UserKnownHostsFile .known_hosts
  1. SSH to the host and accept the known hosts entry
❯ ssh 192.168.0.2 -F ssh_config
The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established.
ECDSA key fingerprint is SHA256:iD5xzH5D6huBYIUpXKaEGPoaPem1yWu0mXAl5lTOXIA.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.2' (ECDSA) to the list of known hosts.
  1. Make sure the known hosts entry for this host doesn't exist in ~/.ssh/known_hosts. Running normal ssh 192.168.0.2 should prompt to accept the host key
❯ ssh 192.168.0.2
The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established.
ECDSA key fingerprint is SHA256:iD5xzH5D6huBYIUpXKaEGPoaPem1yWu0mXAl5lTOXIA.
Are you sure you want to continue connecting (yes/no)?
  1. Use vault ssh to connect to the host
❯ vault ssh -role bastion -mode otp 192.168.0.2 -F ssh_config -vvvv
debug3: hostkeys_foreach: reading file "/Users/mick/.ssh/known_hosts"
failed to run ssh command: exit status 6

Expected behavior
Vault ssh should respect the users ssh_config and not append default values which should be handled by the ssh client. The -o UserKnownHostsFile= flag should only be appended to the ssh command if -user-known-hosts-file has been set. From a technical point of view this would mean removing the default value for -user-known-hosts-file and only appending it when flagUserKnownHostsFile != ""

Environment:

  • Vault Server Version 0.9.5
  • Vault CLI Version Vault v0.10.1 ('756fdc4587350daf1c65b93647b2cc31a6f119cd')

Additional context
I would be more than happy to work on the code part of improving this but I first want to discuss what the behaviour should be like. I'm trying to keep an open mind since maybe there is a very good reason to hardcode this that I might be missing.

Crazybus added a commit to Crazybus/vault that referenced this issue Jun 1, 2018
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 hashicorp#4672
jefferai pushed a commit that referenced this issue Jun 1, 2018
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 #4672
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant