I have a root server where I disabled login via user root and created another user that is in the sudoer list. So when I want to work on the server I do:
ssh [email protected]_ADDRESS
On the server:
enter my password to get root rights. This worked fine for 6 months now. Today I get this message when doing
sudo: no tty present and no askpass program specified
What the hack is happening? What does this error mean and why do I get it?? Without root rights I cannot do so much on the server. Any idea how to fix this?
sudo tries to open
/dev/tty for read-write and prints that error if it fails. You’ve indicated in comments that /dev/tty is missing on your system.
Sudo has an option
-S to read the password from standard input instead of /dev/tty. You should be able to run
sudo -S to become root.
Regarding how to recover /dev/tty, It’s possible that rebooting the server would be sufficient; the system might recreate all devices in /dev during bootup. Alternately, to create a device, you use the
mknod command, but you need to know the correct major and minor numbers for the tty device. On an Ubuntu system I have available, I see these entries in /dev:
crw------- 1 root root 5, 1 Apr 16 18:36 console
crw-rw-rw- 1 root tty 5, 2 Sep 24 15:35 ptmx
crw-rw-rw- 1 root tty 5, 0 Sep 24 14:25 tty
In this case, the major number is 5 and the minor number is 0. /dev/console and /dev/ptmx have the same major number. So I’d inspect /dev/console or /dev/ptmx to find the correct major number, then run:
mknod /dev/tty c major 0
where “major” is the correct major number.
After recreating /dev/tty, make sure the permissions are correct:
chmod 666 /dev/tty
It fails, because
sudo is trying to prompt on root password and there is no pseudo-tty allocated.
You’ve to either log-in as root or set-up the following rules in your
# Members of the admin group may gain root privileges.
%admin ALL=(ALL) NOPASSWD:ALL
Then make sure that your user belongs to
admin group (or
Ideally (safer) it would be to limit root privileges only to specific commands which can be specified as
%admin ALL=(ALL) NOPASSWD:/path/to/program
One thing to check is whether the OS thinks that the various processes “have a tty”. If you are still having problems, it’s probably worth doing this in both the shell within which you run ssh and the shell within which you run sudo. The easy way to check is the command “tty” – if it returns “not a tty”, that shell doesn’t have a “controlling tty” and cannot open /dev/tty even if it exists in the file system.
Various circumstances can cause a shell to not have been run using a controlling tty, and some of them do not provide any visible warning. E.g., I recently ran into a problem on High Sierra with Emacs shell windows (Cannot open pty under Mac OS High Sierra) — High Sierra uses a different mechanism for allocating pty’s than earlier Mac OS X releases, so if your code isn’t reconfigured for it, it will fail to allocate a pty.