Hi,
I’m in trouble with how to use ansible on jumpbox, here is the issue.
from jumpbox I have to use command sudo ssh box_ip to get login with root permission.
How can I let ansible know to use sudo ssh instead of ssh command to execute ?
Thanks
Ethan
As Ansible will work with your ssh config file (~/.ssh/config), have you tried this:
`
#~/.ssh/config
Host *
ProxyCommand sudo ssh -W %h:%p remote_proxy_system
`
This will proxy ALL systems via the proxy server, using the 'sudo ssh' command. If you don't want it to proxy everything, then you need to replace '*' with a space separated list of remote hosts to match.
Actually scrap that, I misunderstood the use of that command. That won’t work (and will run sudo locally)
That is going to trigger ssh as root. Is ssh usage restricted to root only on the jumpbox or are you just trying to ssh to another system as the root user (in which case ssh -l root 1.1.1.1 would work)?
The jump box restricted only root can ssh to another system with ssh key pairs, common user use sudo ssh do the same thing.
Hello,
I know this is an old thread, but I have exactly the same problem as Ethan.
In our environment, we juse a jump host to access servers.
This is a very hardened and stripped down linux/unix server.
The only way to become root on your server-to-manage is to ssh with your username to the jumphost and then issue a “sudo ssh server-to-manage”.
I can accomplish this in one ssh command with this:
ssh -tt jumpserver "sudo ssh server-to-manage"
Question is how do you accomplish that in Ansible?!
Any advice is much appreciated.
Kind Regards,
Thomas
So you all use roots private key on the jumpbox to access the protected servers?
Forgive me but that seems a bit backwards - you lose audit trail for
the servers being accessed,
since you're all logging in with the same private key (i.e. roots key
on the jump host).
We generally ssh to our jump boxes as non-root users and then ssh
again to the backend servers
from non-root accounts on the jump box.
I know that's not really answering your issue, but I'm curious which
one of us is doing the unusual thing 
Hi Dick,
Well, I have no insight in why this model was choosen.
I guess that it allows strict control to limit all accesses via one hardened jumphost, and only one place to manage sudo stuff.
I will try to go the correct route and ask the security people why the jumpstation is built the way it is, but I fear it will take some time…
Still worth the struggle if it allows us to automate tasks in a safe and efficient way in the future.
(If there are good documentation on how to build a ssh jumphost, I am interested to read up on that).
Meanwhile, the work on my desk remains and I was hoping to find a way to let Ansible do some of the heavy lifting allowing us to use the current infrastructure to get work done.
If anyone has a solution to this I am keen to learn.
Kind Regards,
Thomas
I doubt that ansible is capable of handling this kind of jumphost. A
'normal' jumphost that just forwards the connection and the ssh key
works outside of ansible and does not require much configuration
(mostly setting the hosts up in your ~/.ssh/config).
Well, I have no insight in why this model was choosen. I guess that
it allows strict control to limit all accesses via one hardened
jumphost, and only one place to manage sudo stuff. I will try to go
the correct route and ask the security people why the jumpstation
is built the way it is, but I fear it will take some time... Still
worth the struggle if it allows us to automate tasks in a safe and
efficient way in the future. (If there are good documentation on
how to build a ssh jumphost, I am interested to read up on that).
I would be curious why this setup was chosen. If your are not doing
smart sudo authentication, then your whole setup depends on users
entering their password to do 'sudo ssh ...'. Or worse, all enter the
same root password.
So I can not see any advantages over authenticating via ssh keys on
the target host.
Johannes
Hi Johannes,
Thanks for your reply. I am much of the same opinion after some fruitless attempts.
It probably is not possible to achieve what I need directly with Ansible/ssh.
Sad, but I’ll find some other way to work.
As why this solution was choosen, I cannot say. It’s what we got to work with from joint effort of security- and OS team (I work in application support).
I can only guess that having one point of access in combination with one place to manage sudo rights is the reason.
Best Regards,
Thomas