Issues with ansible provisioner with cloud builder and local ssh proxy

[sivel]

Ansible bug report: ansible/ansible#41377

Packer Version: 1.2.4
Host Platform: macOS
Debug Log: https://gist.github.com/sivel/483fd134f4d8552d6a521901b5265e5c

In the above mentioned bug report, the packer file is defined as:

{
  "min_packer_version": "1.2.3",
  "builders": [
    {
      "type": "googlecompute",
      "ssh_username": "packer",
      "project_id": "<YOUR_PROJECT_ID>",
      "source_image": "ubuntu-1604-xenial-v20180522",
      "zone": "us-central1-f",
      "image_family": "repro-image",
      "image_name": "repro-bug-{{isotime | clean_image_name}}",
      "disk_type": "pd-ssd"
    }
  ],
  "provisioners": [
    {
      "type": "ansible",
      "playbook_file": "./repro-image-playbook.yml",
      "extra_arguments": [
        "--ssh-extra-args",
        "-o IdentitiesOnly=yes"
      ]
    }
  ]
}

We can see the googlecompute builder defines "ssh_username": "packer", however the ansible provisioner does not define a user.

When packer creates the local ssh proxy for communicating with the google compute instance, it utilizes the packer user. Due to no user being supplied for the ansible provisioner, an inventory is created that looks like the following where ansible_user becomes defined as daniel.

default ansible_host=127.0.0.1 ansible_user=daniel ansible_port=51644

The remote host does not have a user daniel, however due to the way that the local proxy seems to work, an ssh command specifying -o User=daniel is ignored, and ssh connects through the proxy to the remote instance as the packer user.

Later, when ansible attempts to perform temp dir building, it executes echo ~daniel, which fails to expand due to the lack of the daniel user, and produces a literal ~daniel.

In the end this causes issues, as a directory is created at /home/packer/~daniel, and commands may fail to find the correct directory when using ~daniel as it is not an absolute path.

This situation would not be possible without the local ssh proxy, that ignores the -o User=daniel configuration. Otherwise, the connection would have failed with an auth error.

As it stands, this allowed ansible to think it was connecting as daniel, but really connected as packer.

[peterhorvath]

define user in your provisioner
"user": "{{user `ssh_user`}}",

[sivel]

define user in your provisioner

Yes, that is the recommendation I made to the OP from the Ansible bug report.

However, I still feel that the current functionality can lead to very unexpected behavior.

[SwampDragons]

Hmm interesting. I can see your concern about this possibly causing very unexpected behaviors. So do you think the Ansible provisioner should throw an error if its user doesn't match the ssh user? Do you think user should be required rather than optional?

[sivel]

I've done some investigation, and the problem is rather complex. What if the playbook exhibits the following behaviors:

1. Uses the inventory file to connect to the host, with user matching this may work initially
2. The playbook later changes the user to connect with, either by remote_user or ansible_user, the proxy would allow this without validation that the new user exists, forcing ansible to log in as the wrong user, or if matching is implemented this functionality would be prohibited.
3. If we are relying on creating new user accounts, there is no way to verify that the passwords for these users allow SSH to connect

The way this proxy is implemented completely obscures user authentication.

[alambike]

I totally agree with this issue, the ssh proxy generate a lot of confusion, because the only error that your get is that user doen't exists, but only in those modules where using ansible_user var.

We have to set ssh_username in builder that match user in ansible provisioner, to have the expected behaviour. But this is not clear following the documentation, maybe some reference to this could be very helpful.

[yongzhang]

define user in your provisioner
"user": "{{user `ssh_user`}}",

What if different builders have different ssh_username?