The securetty message suggests that it doesn't really have a clean environment to authenticate you (e.g. 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. In your case, you are ssh'd into the machine, so you have no display. 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. If you ever see an authentication window take over your screen, that's often a polkit-agent supplied with your desktop environment. When polkit tries to authenticate you, it will do this through a polkit-agent. We usually don't want an unprivileged process/script commanding privileged work. This aversion to scripting authentication is because privileged jobs should be commanded explicitly by users, or by other privileged processes. polkit is similar, but is more complicated and harder to understand. This is a reason why there is no -password option for sudo and why sudo doesn't accept echo 'password' | sudo ls.
probably root: (User is not allowed to run the job, so it'll ask you for the administrator password).īoth polkit and sudo do their best to prevent authenticating scripts. Require authentication as someone else.
Require authentication as your user (confirms that it's a human making the request, and this person is sitting at the terminal).polkit will check its policy configuration and will: systemd asks polkit to if you are allowed to do this. However, when you run systemctl without sudo, you are scheduling a systemd job as your current user. root is always allowed to schedule systemd jobs and so this will always work. When you use sudo systemctl, you are scheduling a systemd job as root. May 21 21:38:05 machine su: pam_unix(su:session): session opened for user by user(uid=1000) May 21 21:38:05 machine su: (to root) robin on pts/1 May 21 21:38:05 machine su: pam_unix(su:auth): Couldn't open /etc/securetty: No such file or directory May 21 21:38:02 machine su: pam_unix(su:auth): Couldn't open /etc/securetty: No such file or directory May 21 21:13:55 machine sudo: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory May 21 21:13:51 machine sudo: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory May 21 21:13:49 machine sudo: pam_unix(sudo:auth): authentication failure logname=user uid=1000 euid=0 tty=/dev/pts/1 ruser=user rhost= use>
May 21 21:13:49 machine sudo: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory May 21 21:13:40 machine sudo: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory Loaded: loaded (/lib/systemd/system/ssh.service enabled vendor preset: enabled)Īctive: active (running) since Fri 19:47:32 UTC 2h 51min ago ssh.service - OpenBSD Secure Shell server.What's this about?īy the way, I have Ubuntu 20.04 LTS on my machine. See system logs and 'systemctl status rvice' for details.Īnd when I run the systemctl status sshd command I get this error: Couldn't open /etc/securetty: No such file or directory.
#Hot schedules authentication failure message password#
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.īefore this happened, if I were to run systemctl commands without sudo, a text response would show, requesting the password for my userīut now, this request doesn't pop anymore! Why is that?d systemctl restart sshdįailed to restart rvice: Interactive authentication required. I don't get why this error pops up every time I want to run the systemctl commands.
0 kommentar(er)
