connect to AWS instance as root doesn't fail

Archives Ansible Project
, ,
1

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: 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

2

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 :frowning:

Bill

3

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

4

ec2 instance - built in root account is “ec2-user” rather as “root” . so use ec2-user to connect

5

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.

6

Hi, I am using Dynamic discovery… or at least aim to in production.

The problem is I have over 250 accounts to do maintenance on and these have anywhere from a handful to over 100 instances in each one, so getting those tagged would be almost as much of an ask as actually doing the maintenance that I have to do.

I am going to proceed without trying root for now – hopefully I can get users to perhaps tag instances with root accounts that must be used as per your email, thanks for that, appreciate it.

Regards

Bill