Skip to content
This repository has been archived by the owner on Jun 12, 2021. It is now read-only.

Provisioning using a bastion does not work on a restricted shell #89

Closed
mcanevet opened this issue Oct 16, 2018 · 6 comments
Closed

Provisioning using a bastion does not work on a restricted shell #89

mcanevet opened this issue Oct 16, 2018 · 6 comments

Comments

@mcanevet
Copy link
Contributor

Provisioning using a bastion requires access to the mkdir command because of this.

However, sometime the sysadmins who set up the bastion allowed only access to the ssh command, so that we can jump to the destination host.

It would be great if this provider could work without trying to store the SSH public keys of the destination host on the bastion.

@radekg
Copy link
Owner

radekg commented Oct 21, 2018

Hey @mcanevet, thank you for the report. Would the assumption be that the bastion has the known hosts file preconfigured?

@mcanevet
Copy link
Contributor Author

Unfortunately no. I still have the message saying that the authenticity of the host can't be established before first login to remote host.

@radekg
Copy link
Owner

radekg commented Oct 21, 2018

The only thing I can think of, is the following:

  • a new setting ansible_ssh_settings.bastion_insecure_no_strict_host_key_checking, default false; if true, -o StrictHostKeyChecking=no is added for ssh connections to the bastion
  • a new setting ansible_ssh_settings.insecure_no_strict_host_key_checking, default false; if true, -o StrictHostKeyChecking=no is added for ssh connection to target host; when going via bastion host, bastion should auto accept the target host key, in this case, bastion would not attempt executing any key scan related commands commands at all

Additionally, having ansible_ssh_settings.bastion_user_known_hosts_file and ansible_ssh_settings.user_known_hosts_file wouldn't hurt either. This way, the administrator could potentially provide a bastion host with known hosts file populated.

@mcanevet
Copy link
Contributor Author

@radekg I think your solutions would work fine.

@radekg
Copy link
Owner

radekg commented Nov 4, 2018

Hi @mcanevet, I'm about to merge #94 which contains the code required for the above workflow.

The example sshagent-local-with-bastion is the closest reflecting the described setup. To validate that the insecure_... settings do what they supposed to, cd into thhat example directory and run:

terraform apply -var "ami_id=${TERRAFORM_PROVISIONER_ANSIBLE_AMI_ID}" \
  -var "region=${R_REGION}" -var "aws_admin_profile=${R_NAME}" \
  -var "vpc_cidr_block=${R_VPC_CIDR_BLOCK}" \
  -var "infrastructure_name=${R_NAME}-local" \
  -var "insecure_no_strict_host_key_checking=true"

Because it takes more than 30 seconds for the SSH to become available on the target, you will need a file like this one: https://github.com/radekg/terraform-provisioner-ansible/pull/94/files#diff-170acbfffb52268849488843675447d2R1.

It seems that the usual SSH options for timeout and retries are not respected, what matters is the timeout and retries from the config file.

Of course, you'll need to set the environment up, as described in Getting started.

radekg added a commit that referenced this issue Nov 4, 2018
* Add support for attributes discussed in #89.

* Write bastion pem file to disk as well. Use the bastion PEM file in ProxyCommand when provisioning local via bastion.

* Clarify newly added options apply to local provisioning only.

* Local no bastion, use new settings. Save bastion known hosts file separate to target known hosts file. Use a UUID for known hosts file name.

* Use bastion known hosts file for ProxyCommand. Construct command env variables regardless of the target being a playbook ar module.

* Local ansible args: add BastionKnownHostsFile.

* Use variables for insecure no host key checking in examples.
@radekg
Copy link
Owner

radekg commented Nov 4, 2018

Resolved with #94.

@radekg radekg closed this as completed Nov 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants