Anything attempting to login remotely as root must be rejected. Peter's policy approach is good for that. Most modern linices will not allow a remote root login, which is correct. There are SSH ways to accomplish the same thing, but depend on trust at both ends. The defaulting by Ansible is reprehensible, but usually should be expected to fail.

On Mon, Feb 15, 2021 at 5:15 AM Peter van Heusden pvh@sanbi.ac.za wrote:

Hi there

I found I had this problem too, when the `become: true` applied to the whole Galaxy play. My current top level playbook (at https://github.com/pvanheus/masters_galaxy_ansible/blob/master/galaxy.yml#L2...) now applies `become: true` as it is needed, and does not apply it to the `galaxyproject.galaxy` role. I found that this avoids Ansible trying to log in as the root user.

Peter

On Mon, 15 Feb 2021 at 07:21, Sandra Maksimovic < sandra.maksimovic@mcri.edu.au> wrote:

...

Hi there,

Would anyone happen to know why Ansible tries to connect to a remote host (CentOS 7) using 'root' during Galaxy role installation?

My playbook has been configured to connect to the remote host using a different user account via SSH, however, the role installation is not honoring this for some reason and continues to use root. The remote host has had SSH root login disabled for security reasons and setting various galaxy user/privsep/become/remote user variables in the group_vars has not had any effect.

TASK [galaxyproject.galaxy : Create galaxy_root] *

fatal: [server_name]: UNREACHABLE! => {"changed": false, "msg": "Invalid/incorrect password: Permission denied, please try again.\r\nPermission denied, please try again.\r\nroot@server_name: Permission denied (publickey,password).", "unreachable": true}

Thanks,

Sandra

This e-mail and any attachments to it (the "Communication") are, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Murdoch Children’s Research Institute (MCRI) ABN 21 006 566 972 or any of its related entities. MCRI does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication. ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: %(web_page_url)s

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: %(web_page_url)s

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/

Thanks Peter, removing the global ‘become: true’ flag in the playbook did not change the outcome for me.

Had to explicitly define galaxy_become_users and galaxy_remote_users like so:

galaxy_become_users: privsep: root errdocs: root galaxy: galaxy root: root galaxy_remote_users: privsep: foo errdocs: foo galaxy: foo root: foo

Where ‘foo’ is the user you want to SSH with.

From: Peter van Heusden pvh@sanbi.ac.za Sent: Tuesday, 16 February 2021 3:42 AM To: Michael Moore michaelglennmoore@gmail.com Cc: Sandra Maksimovic sandra.maksimovic@mcri.edu.au; galaxy-dev@lists.galaxyproject.org Subject: [EXTERNAL]Re: [galaxy-dev] Re: Ansible Galaxy using root user for role installation

CAUTION: External Email. Please be cautious with attachments and clicking links

It is not actually, in my investigation, coming from an Ansible default. There's code inside the Galaxy role that tries to figure out which user to use for remote_user (the one used in SSH) and when it is run with `become: true` ends up incorrectly choosing root. However people more knowledgeable than me don't have this problem. Perhaps something changed in some version somewhere?

Peter

On Mon, 15 Feb 2021 at 17:16, Michael Moore <michaelglennmoore@gmail.commailto:michaelglennmoore@gmail.com> wrote: Anything attempting to login remotely as root must be rejected. Peter's policy approach is good for that. Most modern linices will not allow a remote root login, which is correct. There are SSH ways to accomplish the same thing, but depend on trust at both ends. The defaulting by Ansible is reprehensible, but usually should be expected to fail.

On Mon, Feb 15, 2021 at 5:15 AM Peter van Heusden <pvh@sanbi.ac.zamailto:pvh@sanbi.ac.za> wrote: Hi there

I found I had this problem too, when the `become: true` applied to the whole Galaxy play. My current top level playbook (at https://github.com/pvanheus/masters_galaxy_ansible/blob/master/galaxy.yml#L2...https://github.com/pvanheus/masters_galaxy_ansible/blob/master/galaxy.yml#L25) now applies `become: true` as it is needed, and does not apply it to the `galaxyproject.galaxy` role. I found that this avoids Ansible trying to log in as the root user.

Peter

On Mon, 15 Feb 2021 at 07:21, Sandra Maksimovic <sandra.maksimovic@mcri.edu.aumailto:sandra.maksimovic@mcri.edu.au> wrote: Hi there,

Would anyone happen to know why Ansible tries to connect to a remote host (CentOS 7) using 'root' during Galaxy role installation?

My playbook has been configured to connect to the remote host using a different user account via SSH, however, the role installation is not honoring this for some reason and continues to use root. The remote host has had SSH root login disabled for security reasons and setting various galaxy user/privsep/become/remote user variables in the group_vars has not had any effect.

TASK [galaxyproject.galaxy : Create galaxy_root] * fatal: [server_name]: UNREACHABLE! => {"changed": false, "msg": "Invalid/incorrect password: Permission denied, please try again.\r\nPermission denied, please try again.\r\nroot@server_name: Permission denied (publickey,password).", "unreachable": true}

Thanks, Sandra

This e-mail and any attachments to it (the "Communication") are, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Murdoch Children’s Research Institute (MCRI) ABN 21 006 566 972 or any of its related entities. MCRI does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication. ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: %(web_page_url)s

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/http://galaxyproject.org/search/ ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: %(web_page_url)s

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/http://galaxyproject.org/search/

Hi Keith,

I did try that but it didn’t make any difference. I’ve even tried disabling privilege separation entirely but that had no effect either.

Thanks, Sandra

From: Keith Suderman suderman@jhu.edu Sent: Wednesday, 17 February 2021 5:42 AM To: Sandra Maksimovic sandra.maksimovic@mcri.edu.au Cc: galaxy-dev@lists.galaxyproject.org Subject: [EXTERNAL][galaxy-dev] Re: Ansible Galaxy using root user for role installation

CAUTION: External Email. Please be cautious with attachments and clicking links

Hi Sandra,

My initial hunch is that Ansible is trying to use root to create the galaxy_privsep_user. Have you set galaxy_create_privsep_user to false in the group_vars?

Cheers, Keith

On Feb 15, 2021, at 12:21 AM, Sandra Maksimovic <sandra.maksimovic@mcri.edu.aumailto:sandra.maksimovic@mcri.edu.au> wrote:

Hi there,

Would anyone happen to know why Ansible tries to connect to a remote host (CentOS 7) using 'root' during Galaxy role installation?

My playbook has been configured to connect to the remote host using a different user account via SSH, however, the role installation is not honoring this for some reason and continues to use root. The remote host has had SSH root login disabled for security reasons and setting various galaxy user/privsep/become/remote user variables in the group_vars has not had any effect.

TASK [galaxyproject.galaxy : Create galaxy_root] * fatal: [server_name]: UNREACHABLE! => {"changed": false, "msg": "Invalid/incorrect password: Permission denied, please try again.\r\nPermission denied, please try again.\r\nroot@server_name: Permission denied (publickey,password).", "unreachable": true}

Thanks, Sandra

This e-mail and any attachments to it (the "Communication") are, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Murdoch Children’s Research Institute (MCRI) ABN 21 006 566 972 or any of its related entities. MCRI does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication. ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: %(web_page_url)s

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/http://galaxyproject.org/search/