Cannot SUDO SU anymore, "no tty present and no askpass program specified"

7
votes

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 myusername@IP_ADDRESS

On the server:

sudo su

enter my password to get root rights. This worked fine for 6 months now. Today I get this message when doing sudo su:

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?

3
linuxsshsudo
Try logging in with ssh -t username@host, and please, don't use "sudo su", there's a switch to sudo especially for this purpose. Use sudo -s instead, or just su if you'd like to type the root password. – superjedi
@superjedi does not work either. Even with the root password. I think I have to reset the server tonight because I have no idea why it is not working. – Upvote
When you log into the remote server (and before running sudo), do you actually have a tty? Running "tty" should print the name of your tty. After that, I'd check the permissions on your tty device and on "/dev/tty" to see if they're screwed up. – Kenster
@Kenster I get crw--w---- 1 username tty 136, 2 Sep 24 2014 /dev/pts/2 – Upvote
sudo actually opens "/dev/tty" for read-write and prints that error if it fails. Check the perms on that. – Kenster

3 Answers

19
votes

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
7
votes

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 /etc/sudoers (or: sudo visudo):

# 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 wheel).

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

0
votes

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.