Ansible-remote provisioner and SSH port forwarding

[Julian Santander]

Hello,

I'm trying to use some ansible scripts that I've developed for a different environment and adapt them to the ansible-remote provisioner of packer.

One trick I used in those scripts is to set a remote port forwarding to ansible's ssh connection arguments for some tasks. This way I can, for example, temporarily forward the corporate proxy (which is accessible to the ansible runner, but it is not to the host being installed).

This is not working when launched by the ansible-remote provisioner and I'm not sure what is preventing it to work.

The error I see in the ansible verbose trace is:

debug1: remote forward failure for: listen 1234, connect mycorporate-proxy:8000
Warning: remote port forwarding failed for listen port 1234

I don't think this is a problem with the guest SSH configuration as running some simple ssh command to the NAT forwarded port for SSH that the builder sets up, the remote port forwarding setting succeeds.

Reading the documentation I seem to gather that some SSH server is brought up at the host to receive the connection attempts from ansible. Now, since I believe the guest SSHD accepts remote port forwarding, it might be a question that this host SSH server is the one that cannot accept the forwarding.

For what is worth, this is packer 1.2.4, with Ubuntu 18.04 as host and using the virtualbox-ovf builder 

The questions are:

1. Am I missing anything?
   
2. Is there any configuration parameter controlling whether remote port forwarding is accepted?
3. Would there be a way of using directly the guest SSHD without any intermediary? (I guess this would involve at least knowing the NATed SSH port set by the builder)

Thanks very much in advance and best regards

Julian

[Rickard von Essen]

Hi, your analysis is overall correct.  

Reading the documentation I seem to gather that some SSH server is brought up at the host to receive the connection attempts from ansible. Now, since I believe the guest SSHD accepts remote port forwarding, it might be a question that this host SSH server is the one that cannot accept the forwarding.

This is correct with one minor correction, it's not sshd, it's Packer itself that run some native Go code that act as a ssh server.

1. Am I missing anything?

No

2. Is there any configuration parameter controlling whether remote port forwarding is accepted?

No

3. Would there be a way of using directly the guest SSHD without any intermediary? (I guess this would involve at least knowing the NATed SSH port set by the builder)

You can try overriding the inventory file and create your own with the shell-local provisioner before invoking ansible. This requires that you get the IP of the guest, depending on your builder there are different methods to do this.

If you step back and see if you can get the shell provisioner to work I think it will solve all you problems. Have you tried using ssh_proxy_host 1) et.al.?

As a workaround it can be simpler to just spin up a machine in your target environment and run Packer from that.

1) https://www.packer.io/docs/templates/communicator.html#ssh_proxy_host 

PS. The correct solution is to walk over to the network department and inform them that they are hindering work without any security benefits.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/412c9058-9a4a-4dd2-a183-bc47b6420944%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julian Santander]

Thanks very much for your quick answer.

In the end, the solution was evident once I stepped back and looked at the whole picture (as soon as I closed everything and got in the car to go back home): I didn't need any magical port-forwarding as the VM already had access to the corporate process through a NAT interface. Once I tweaked my scripts proxy settings I was able to do what I wanted.

Thanks again

Julian