Sudo: sorry, you must have a tty to run sudo

trellis
1

I’ve got a client who set up an EC2 instance for me to deploy to, along with a single user who has sudo access and a .pem key.

I’ve added this password to the vault_users for the environment, but at the “WordPress Server - Install LEMP Stack with PHP and MariaDB MySQL” task, I’m getting the following:

sudo: sorry, you must have a tty to run sudo

Running tty --version on the remote server returns the following though:

tty (GNU coreutils) 8.22

I’m not by any means suggesting anything is wrong with trellis here, but I’m wondering whether anyone has run into this, and whether I need them to set my user up differently.

If I ssh directly into the server and attempt to sudo, I am prompted for a password and can successfully sudo though.

Additionally, this is happening after I changed the admin_user to the user that they provided for me, and I’m wondering whether this was correct.

Any help at all is appreciated.

2

By default EC2 instances don’t allow root login, so you may need to disable this as per: Remote Server Setup | Trellis Docs | Roots - See point 5

The default sudo user (admin_user) created via ec2 setup tends to be ubuntu you need to add this to your users.yml or the custom one created.

If you’ve tried to connect to this server and accepted ECDSA keys already, you may also need to clean / remove that key from your known_hosts file on your local machine too

When creating the EC2 Instance you tend to also create a unique SSH key for login, you may need to setup the config for that in your ssh_config file if it differs from your own machines default ssh key

2 Likes
3

Thanks for the response. I forgot to mention that I did set sshd_permit_root_login: false.

I also do have the admin_user set to the user they created for me, and “sudo” is included in the admin_user’s groups.

The unique ssh key is loaded into my keychain and is being used (I initially tried prior to doing this and received the “Data could not be sent to remote host” as I’d expect) — so it appears that ansible is successfully connecting (as the user I’m specifying) and that isn’t the issue.

I’ve also got the “Become” password added to the vault_users, though I’ve provided it explicitly through the --ask-become-pass flag as well with the same results.

4

You may be able to get a better idea of what’s happening by running a raw Ansible command with verbose output:

ansible-playbook server.yml -e "env=production site=YOURMAINDOMAIN.COM" -vvvv

Ref: Troubleshooting | Trellis Docs | Roots

1 Like
5

I tried that and also set no_log to “true” in the relevant places, but it unfortunately didn’t give me anything additional and useful surrounding the actual failure. This is the end of my output

`
TASK [connection : Warn about change in host keys] *******************************************************************************************
skipping: [production_host] => {“changed”: false, “false_condition”: “‘REMOTE HOST IDENTIFICATION HAS CHANGED’ in connection_status.stdout”, “skip_reason”: “Conditional result was False”}

TASK [connection : Set remote user for each host] ********************************************************************************************
ok: [production_host] => {“ansible_facts”: {“ansible_user”: “[MY_SPECIFIED_USER]”}, “changed”: false}

TASK [connection : Announce which user was selected] *****************************************************************************************
ok: [production_host] => {
“msg”: “Note: Ansible will attempt connections as user =[MY_SPECIFIED_USER]\n”
}

TASK [connection : Load become password] *****************************************************************************************************
ok: [production_host] => {“ansible_facts”: {“ansible_become_pass”: “{% for user in vault_users | default() if user.name == ansible_user %}{{ user.password | default(‘’) }}{% endfor %}”}, “changed”: false}

PLAY [WordPress Server - Install LEMP Stack with PHP and MariaDB MySQL] **********************************************************************

TASK [Gathering Facts] ***********************************************************************************************************************
fatal: [production_host]: FAILED! => {“ansible_facts”: {}, “changed”: false, “failed_modules”: {“ansible.legacy.setup”: {“ansible_facts”: {“discovered_interpreter_python”: “/usr/bin/python”}, “failed”: true, “module_stderr”: “sudo: sorry, you must have a tty to run sudo\n”, “module_stdout”: “”, “msg”: “MODULE FAILURE\nSee stdout/stderr for the exact error”, “rc”: 1}}, “msg”: “The following modules failed to execute: ansible.legacy.setup\n”}

PLAY RECAP ***********************************************************************************************************************************
localhost : ok=0 changed=0 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
production_host : ok=4 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0
`

6

I suspect that when your sudo account has been created it’s been done with requiretty - I’ve never had this issue personally, normally Ubuntu 22.04 does not enable this by default. Are you sure the machine you’re reaching is not a CentOS machine?

Basically your box is saying the user running this command isn’t actually in a live session with me, it’s being ran via piping through a different session so I don’t trust them to run sudo commands.

You need to have requiretty commented out/excluded in your sudoer account in /etc/sudoers. To the best of my knowledge this isn’t default behaviour but would be keen to hear if this is a new AWS default for security - might help future users

1 Like
7

It looks like it was created with requiretty — along with several other things that weren’t done correctly — like the entire OS being an incorrect Linux distro (they installed Cent OS).

Not a whole lot to take away from this one other than confirm the OS of the server before you try to do anything else…

Thanks for chiming in and at least helping to check my sanity on this one. It’s much appreciated.

1 Like
8

I’ll be honest @brianbattenfeld, after helping out and you choosing your own answer as the solution I’m a little upset, but I’m learning to come to terms with it :upside_down_face:

9

I just changed to give yourself the credit for the answer. I honestly thought of it as being outside of what we were even looking at due to the entire OS being off, but you are totally right and pointing out the requiretty value in the sudoers file and should get that credit.

Thanks again for the help.

1 Like