We have our own amis that do use root, not my doing, but they exist…. And CentOS user is CentOS, so you can’t just use ec2-user blindly.
From: [email protected] <[email protected]> On Behalf Of Jaya Nehru Kumar Sent: Sunday, July 14, 2019 4:00 AM To: Ansible Project <[email protected]> Subject: Re: [ansible-project] Re: connect to AWS instance as root doesn't fail ec2 instance - built in root account is "ec2-user" rather as "root" . so use ec2-user to connect On Friday, July 12, 2019 at 12:26:14 AM UTC+2, Pshem Kowalczyk wrote: Hi, The following solution comes to mind - on the controller run a playbook that connects to the instances using the 'command' or 'shell' module (so delegate_to: localhost) and inspect the output of the ssh command. Based on the output of that playbook - create an inventory that stores ansible_ssh_user. If you rely on dynamic inventory - I suggest trying to figure out if you can Tag instances with information about the type of user to use and then hack the dynamic inventory script to turn those tags into 'ansible_ssh_user' variable. kind regards Pshem On Fri, 12 Jul 2019 at 04:29, William Dossett <[email protected] <javascript:> > wrote: Ok, when running this with -vvvv (managed to whittle down the output and see what I think the problem is...) it connects and does not get a "server refused our key" type error... it connects and then tells us to connect with another user and then closes the session with no error message. Broken pipe\r\ndebug2: Received exit status from master 0\r\nShared connection to 10.5.162.167 closed.\r\n", "module_stdout": "Please login as the user \"ec2-user\" rather than the user \"root\".\r\n\r\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 0 so we get a broken pipe.... unfortunately I have no idea how to handle this. Anyone, any ideas? Tearing out what little hair I have left over this :-( Bill On Thursday, July 11, 2019 at 10:15:45 AM UTC-6, William Dossett wrote: Hi, I tagged this onto the end of another question and didn’t get any answers… so am trying to figure it out myself, but the more I look at it the more I don’t understand. AWS Linux instances do not allow connecting via SSH as root by default… if you ssh as root, it tells you to connect as ec2-user and then just disconnects after a few seconds. So I am trying to create a playbook to connect to all AWS Linux instances, AWS, RHEL, Centos, Ubuntu. They have different users, so I am trying different users until it works and the run the rest of the playbook. (you can also have your own AMIs and instance that may only have root enabled) The problem is when I try to connect to this AWS Linux instance as root, it doesn’t fail. I get TASK [try users] ****************************************************************************************************************************** [WARNING]: Unhandled error in Python interpreter discovery for host 10.5.162.167 <http://10.5.162.167> : unexpected output from Python interpreter discovery [WARNING]: sftp transfer mechanism failed on [10.5.162.167]. Use ANSIBLE_DEBUG=1 to see detailed information [WARNING]: scp transfer mechanism failed on [10.5.162.167]. Use ANSIBLE_DEBUG=1 to see detailed information [WARNING]: Platform unknown on host 10.5.162.167 is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change this. See https://docs.ansible.com/ansible/2.8/reference_appendices/interpreter_discovery.html for more information. ok: [10.5.162.167] So I am unable to fathom why it seems to be connected and finding a python interpreter at /usr/bin/python … how does it get that far and why doesn’t it just fail? It produces warnings, but ultimately an OK which means it will then try and run the rest of the playbook – I guess that would fail eventually, but that seems sloppy. If I connect as another user that doesn’t exist it fails with permission denied. Any advice would be greatly appreciated as I am about out of ideas right now. Thanks Bill -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <javascript:> . To post to this group, send email to [email protected] <javascript:> . To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/53e35651-63ba-4bf6-9a7f-c6267b5c851d%40googlegroups.com <https://groups.google.com/d/msgid/ansible-project/53e35651-63ba-4bf6-9a7f-c6267b5c851d%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To post to this group, send email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/56df74de-589b-4326-9e79-d5e21f42ff6a%40googlegroups.com <https://groups.google.com/d/msgid/ansible-project/56df74de-589b-4326-9e79-d5e21f42ff6a%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/006b01d53a4c%246fc9cf80%244f5d6e80%24%40gmail.com. For more options, visit https://groups.google.com/d/optout.
