Hi,
Monica wrote:
Thank you for sharing the same, however, I have already
checked this article.
I was simply quoting the article which Will kindly shared to
mention that ProxyJump / -J might be a simpler method, even
within ansible_ssh_common_args.
[I reformatted some of the text you wrote as it arrived at
the list as one large block, which was rather hard to read.]
I have a requirement to connect Host-A then I can connect
Host-B. I can’t connect Host-B directly. So in this case
how to execute the playbook task on Host-B from Control
Machine? Because my control machine is centralized. Hence,
my question is how to execute the playbook task on Host-B
directly from the control machine via bastion host-: Below
is an example of how I am connecting to the remote host
via bastion host using ssh.
ssh user@<remote-host IP>@<bastion-host-IP> -p 8022
Note that the ssh_config man page says of ProxyJump:
Specifies one or more jump proxies as either
[user@]host[:port] or an ssh URI.
It has further text regarding configuration applied to the
jump (aka bastion) host, which is worth reading.
Ansible uses the value from `ansible_ssh_common_args` to
create the full ssh command to connect to each host, so
`@<remote-host>` should not be included if you're using
ansible to connect to <remote-host> via <bastion-host>.
(If you've got multiple bastion hosts to pass through from
<control-host> to <remote-host>, you should probably get
things working with ssh directly and then map that to either
`ansible_ssh_common_args` or the `.ssh/config` of the user
running ansible on the control host.)
All that said, if you're going from <control-host> to
<remote-host> via <bastion-host> (on port 8022), I think
this would look like:
ansible_ssh_common_args='-J <bastion-user>@<bastion-host>:8022'
(I skipped the StrictHostKeyChecking option there simply for
brevity. I replaced -o ProxyJump with -J for the same
reason.)
That connects to the <remote-host> via the bastion host as
the given user and at the given port.
I find testing with the ansible ping module is helpful in
cases like this. It makes it easier to separate issues with
the playbook from issues with the ssh configuration. E.g.:
ansible <remote-host> -om ping
That should return:
<remote-host> | SUCCESS => {"changed": false,"ping": "pong"}
If not, adding -vvv to the command will show the ssh command
ansible used, which can be checked for sanity (and/or
compared to what works when you run ssh directly to get from
<control-host> to <remote-host> via <bastion-host>).