Why is this error: "Interactive authentication required" popping up?

Question

I don't get why this error pops up every time I want to run the systemctl commands. I know that I have to run it with sudo, which runs just fine, but I am curious, why is this happening? It didn't happen before, and I didn't do anything special, other than configuring my /etc/ssh/sshd_config file.

Before this happened, if I were to run systemctl commands without sudo, a text response would show, requesting the password for my user

But now, this request doesn't pop anymore! Why is that?d

user@machine:~$ systemctl restart sshd
Failed to restart sshd.service: Interactive authentication required.
See system logs and 'systemctl status sshd.service' for details.

And when I run the systemctl status sshd command I get this error: Couldn't open /etc/securetty: No such file or directory. What's this about? By the way, I have Ubuntu 20.04 LTS on my machine.

user@machine:~$ systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2021-05-21 19:47:32 UTC; 2h 51min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 14021 (sshd)
      Tasks: 5 (limit: 38329)
     Memory: 1.7G
     CGroup: /system.slice/ssh.service
             ├─14021 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
             ├─20182 ssh-server new -c 256 -s -l LANG=en_US.UTF-8
             ├─20183 -bash
             ├─46248 systemctl status sshd
             └─46249 pager

May 21 20:58:15 machine sshd[19925]: Disconnected from user user 217.138.209.001 port 2222
May 21 21:13:40 machine sudo[20203]: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
May 21 21:13:49 machine sudo[20203]: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
May 21 21:13:49 machine sudo[20203]: pam_unix(sudo:auth): authentication failure; logname=user uid=1000 euid=0 tty=/dev/pts/1 ruser=user rhost=  use>
May 21 21:13:51 machine sudo[20203]: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
May 21 21:13:55 machine sudo[20203]: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
May 21 21:38:02 machine su[34300]: pam_unix(su:auth): Couldn't open /etc/securetty: No such file or directory
May 21 21:38:05 machine su[34300]: pam_unix(su:auth): Couldn't open /etc/securetty: No such file or directory
May 21 21:38:05 machine su[34300]: (to root) robin on pts/1
May 21 21:38:05 machine su[34300]: pam_unix(su:session): session opened for user by user(uid=1000)

Answer 1

When you use sudo systemctl, you are scheduling a systemd job as root. root is always allowed to schedule systemd jobs and so this will always work.

However, when you run systemctl without sudo, you are scheduling a systemd job as your current user. systemd asks polkit to if you are allowed to do this. polkit will check its policy configuration and will:

1. Approve you (no password required)
2. Require authentication as your user (confirms that it's a human making the request, and this person is sitting at the terminal).
3. Require authentication as someone else... probably root: (User is not allowed to run the job, so it'll ask you for the administrator password).

Both polkit and sudo do their best to prevent authenticating scripts. This is a reason why there is no --password option for sudo and why sudo doesn't accept echo 'password' | sudo ls. polkit is similar, but is more complicated and harder to understand. This aversion to scripting authentication is because privileged jobs should be commanded explicitly by users, or by other privileged processes. We usually don't want an unprivileged process/script commanding privileged work.

When polkit tries to authenticate you, it will do this through a polkit-agent. If you ever see an authentication window take over your screen, that's often a polkit-agent supplied with your desktop environment. But to connect to the appropriate polkit-agent, it needs to know a bit about your $DISPLAY and $XAUTHORITY so the prompt occurs in the correct session.

In your case, you are ssh'd into the machine, so you have no display. In that case it "falls back" on a textual agent, but there seems to be a problem in that either your agent is authenticating you as a user, and not as root, or it is authenticating you but later realizes that you do not have permission to schedule systemd jobs. The securetty message suggests that it doesn't really have a clean environment to authenticate you (e.g. another process could intercept your stdin, or it can't verify that you're a real person and not a script).

Regardless of the reason, the root cause is the fact that you are ssh'd into that machine and don't have permission to schedule systemd jobs.

You have two options:

1. Use sudo systemctl. This is the simplest solution, but if there is some reason that this is unacceptable (i.e. you are scripting systemd jobs and don't want to add :NOPASSWD to /etc/sudoers) then do mention it.

2. Create a polkit rule to allow you to run systemd jobs as a user. There's a good answer which describes how to do that here.