On Sun, Jun 08, 2014 at 02:42:41AM +0100, Michael Scherer wrote: > And after a quick crude test, if you have ssh listening on 2 ports, ssh > will treat each as a different entry in known_hosts, and so ask again. > ( or at least on my laptop, I didn't dig more given the hour, will try > to search a bit more ). Yes, I thought about it some more as well. This might indeed be a problem. I see two kind of attacks. The one you describe is only interesting for someone who is able to run ansible for a host but does not have root access to the host. If it is possible to specify a non-privileged port (e.g. 1234), the attacker can run its own SSH server there to get access to all information sent by ansible but only for the host the attacker has already access to. The required privileges are: - Being able to login to a host - Being able to run playbooks for a host - Being able to specify the port for ansible to connect to The attacker does not gain any advantage if they have already root access to the host. Getting information from a different host requires to modify the playbook/ansible repo to send the wrong credentials from the private repo to the system the attacker has access to. But then it could be stored in a way that it is accessible for the attacker without root access, so being able to change the port is not necessary. Another possible attack is to run the playbook on a different host. For this an attacker could forward the ssh port from target01 to attacker01:1234 and run the playbook for attacker01 but port 1234. Then it will be executed on target01, if ansible uses the right SSH private key automatically and the same sudo password or no sudo password. If the attacker has root access attacker01, they could also forward attacker01:22 to target01:22, so being able to specify a port to ansible is not required. But this requires the ssh hostkey not being checked. Regards Till _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
