1

On an Amazon Linux 2 EC2 instance, password authentication from remote users has been enabled by running the following command during the cloud-init startup script: sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config . As a result, remote users do not use a keypair to authenticate when logging in to the Amazon Linux 2 EC2 instance. One of those users, someuser , needs to be able to run sudo commands without typing in a password.

Cloud-Init Startup Script

The full cloud-init startup script is as follows:

/usr/sbin/useradd someuser
echo someuser:some-password | chpasswd
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
systemctl restart sshd  

cat << 'EOF' > /etc/sudoers.d/someuser
someuser ALL=(ALL) NOPASSWD: ALL
EOF


Question

What specific syntax needs to be used in the above cloud-init startup script in order to enable someuser to run sudo commands without restating their password, but while still enabling someuser to login remotely via Putty using their given password?


The error message

The following screen shot illustrates the error message:

Remote login rejected


Toggling The Error

The above current syntax results in someuser not being able to Putty in due to a lack of a Public key. However, the error can be removed, so that someuser is able to log in, but is NOT able to perform sudo commands, if the 3 line cat command is commented out of the above:


  #cat << 'EOF' > /etc/sudoers.d/someuser   
  #someuser ALL=(ALL) NOPASSWD: ALL   
  #EOF



The problem is in the preceding 3 lines posted here at the end. How can these 3 lines be rewritten, replaced, or augmented to enable this user to elevate to sudo without a password while still retaining the ability to Putty in using only a password?

Improve this question
9
  • AFAIK sshd and sudo are orthogonal. Are you sure something else isn't failing in that script that is killing your sshd setup?
    – Aaron D. Marasco
    Jun 17, 2020 at 20:52
  • @AaronD.Marasco The problem is isolated to 3 lines that attempt to set up sudo access for someuser. The OP asks precisely what you point out, which is what is failing in these 3 lines?
    – CodeMed
    Jun 17, 2020 at 21:36
  • The rendering issue that appears in revision 3 of this question (code displayed as code in the preview, as normal text after the edit is saved) is interesting. With the aim of a bug report I tried to reproduce it in the experimentation sandbox on Meta U&L (removing the actual text and keeping spacing, HTML tags and markdown), but I couldn't come up with any working repro steps.
    – fra-san
    Jun 17, 2020 at 22:30
  • someuser should belog to sudo group, i used to create new user like this: adduser someuser ;addgroup someuser; adduser someuser someuser; adduser someuser sudo
    – Yunus
    Jun 18, 2020 at 14:57
  • @Jonah Your suggested code does not resolve the problem. I commented out the part that removes the error as shown in the OP, then I added your code instead of the way the user is added in the OP, but the same error resulted. I can still turn off the error by reverting to the non-sudo state shown in the OP. I also added a screen shot of the error to the OP. Can you have a look at the screen shot and suggest anything else?
    – CodeMed
    Jun 18, 2020 at 16:02

1 Answer 1

Reset to default
2

from /etc/sudoers.d/README :

It's recommended to use visudo , because it'll prevent making changes in case of errors , and also it'll deal with new file mode (0440).

which means your init script needed only a mode-change to the new created file (/etc/sudoers.d/someuser)

chmod 0440 /etc/sudoers.d/someuser;

But the solution you did find here is better ,

echo 'someuser ALL=(ALL:ALL) ALL' | sudo EDITOR='tee -a' visudo

Visudo here will use tee insteed of nano to append new content without interaction , and that's the magic that i missed!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .