communicator/ssh: support for bastion SSH

[mitchellh]

Fixes #387

This builds on #1721 and makes an SSH bastion host available to all builders.

For docs I still want to do a bigger communicator section for the docs, so leaving it out for now since I inevitably have to go over every communicator config anyways.

[phinze]

Code LGTM!

Bastions are sort of annoying without an ssh-agent. Looks like no agent support in normal SSH functionality either, so not expecting that here.

In the meantime, I wonder if it'd be convenient to default SSHBastionPrivateKey to SSHPrivateKey, since that's a common property of bastion-using environments (same key for jump as for internal hosts). I believe the SSH handshake mechanism is such that there aren't any security implications of offering up a private key to a server, so that angle shouldn't be a problem IIRC.

[mitchellh]

@phinze Packer just always uses the local SSH agent if it finds it. It is opt-out, vs. opt-in like Terraform.

Sounds good to default it.

[phinze]

Oh nice! Based on some anecdotal user feedback - I'm hoping to make Terraform's opt-out too. 👍

[nathanielks]

Ah, brilliant timing! @mitchellh would it be possible for a quick overview on how to set this up?

[mitchellh]

@nathanielks This should help: https://packer.io/docs/templates/communicator.html

[nathanielks]

@mitchellh You're awesome.

[ervansetiawan]

I am a little bit unclear on how the communicator should work. We are running Packer behind a corporate firewall and we would like to create AMIs. I was able to set up ssh tunneling over https using corkscrew and was able to ssh to an ec2 instance from behind the firewall.

My understanding is Packer can't take advantage of that and ssh communicator can be used to solve this problem but I am not sure why.

Can someone elaborate on that?

[tamsky]

/cc @mitchellh commented on Jun 17:

@phinze Packer just always uses the local SSH agent if it finds it.

I'd like to report that my local ssh agent is never utilized. I'm running v0.8.6.

I'm using 'amazon-ebs' with ssh_keypair_name set to an existing key in AWS.
The associated private key for that keypair is in my local agent's keychain.

For reasons possibly starting in/around #1837 , when ssh_keypair_name is set, Packer also requires ssh_private_key_file to not be null, and point to a valid private key. This might be a regression. For entertainment purposes, I created a one-off temporary private key and point ssh_private_key_file at it.... hoping that my ssh agent will actually get used. It doesn't.

If the ssh agent was consulted, this would not be an issue.

The one-off temporary private key credentials I created are being exclusively used instead.

Proof:
While Packer is performing ssh handshake retries, I copy the one-off temporary public key (using my agent credentials) to the remote host's .ssh/authorized_keys (and fix permissions). Packer's SSH Handshake then succeeds and the build continues.

[amosshapira]

+1 for @tamsky 's report - my ssh-agent doesn't get used to access the bastion host.

[jeffawang]

+1 for @tamsky and @amosshapira report of no ssh-agent support for bastions. I am running packer 0.8.6:

$ ssh-add -l > /dev/null && echo $?
0

$ packer -version
0.8.6

$ packer build packer.json
amazon-ebs output will be in this color.

1 error(s) occurred:

* ssh_bastion_password or ssh_bastion_private_key_file must be specified

[LongLiveCHIEF]

Am I correct in assuming that when you run a packer template using bastion_ communicator settings, it assumes that the machine running packer is your bastion host (unless otherwise specified), and that it should work if you give it the right communicator settings for the ssh-agent running on that same machine?

[rickard-von-essen]

@LongLiveCHIEF No, see OpenSSH and a Bastion server.

[LongLiveCHIEF]

Thanks @rickard-von-essen !

[shiroglazov]

In our current company bastion host is conigured to use 2FA, so neither static password or private key are not cutting it. I wonder if we have feature request to either use control socket (ssh -S) or, at the very least, provide a way of asking two-factor credentials during packer runtime.