Cannot Sudo Su Anymore, "No Tty Present and No Askpass Program Specified"

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

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

redhat linux sudo su - failed

It seems to be a known bug of CentOS and Redhat:

0011249: su: avc.c:74: avc_context_to_sid_raw: Assertion `avc_running'
failed.

Description Whenever I execute a su - command after switching
into the sysadm_r, I get this fault. The system is in enforcing mode
when I get this error. When in permissive mode, this does trigger the
error. Attempted to address the problem with audit2allow to see if
that could temporarily resolved the problem while I looked for a
permanent solution but that did not work either

There are the 2 referencies:

• Centos bug

• RedHat Bug

Ansible synchronize prompts passphrase even if already entered at the beginning

The synchronize command (up to at least Ansible 1.6.6) seems to ignore the normal SSH control socket opened by Ansible. Your task could expand to the following:

{
    "cmd": "rsync --delay-updates -FF --compress --archive
        --rsh 'ssh  -o StrictHostKeyChecking=no'
        --out-format='<<CHANGED>>%i %n%L'
        /home/me/src/ user@host:/dest/",
    "failed": true,
    "rc": 23
}

To get these details, run your playbook with the -v option. As a workaround for this, you can start ssh-agent and add cache your SSH key with ssh-add. Refer to their manual pages for details.

Extra caveats with the synchronize module:

• When run with sudo: yes, ansible will run with --rsh 'sudo ssh' which will break if the remote sudo configuration requires a password and/ or TTY. Solution: set sudo: no in your task definition.
• The user that logs into the remote machine is your SSH user (ansible_ssh_user), not the sudo user. I have not found a way to override this user (besides an untested method that overrides the user with -o User option via one of the other options (dest_port="22 -o User=your_user"?) in combination with set_remote_user=yes).

This is taken from my tasks file:

- name: sync app files
  sudo: no
  synchronize: src={{app_srcdir}}/ dest={{appdir}}/
               recursive=yes
               rsync_opts=--exclude=.hg
# and of course Ubuntu 12.04 does not support --usermap..
#,--chown={{deployuser}}:www-data
# the above goes bad because ansible_ssh_user=user has no privileges
#  local_action: command rsync -av --chown=:www-data
#                 {{app_srcdir}}
#                 {{deployuser}}@{{inventory_hostname}}:{{appdir}}/
#  when: app_srcdir is defined
# The above still goes bad because {{inventory_hostname}} is not ssh host...

Ubuntu server sudo error AWS EC2

Its a bit lengthy procedure, but I got a way out. The ultimate objective is to gain access to root user.
Step 1- Add a new user that does not need .ppk key to login.
1. Firstly stop your faulty instance and make a copy of the same EC2 instance.
2. Now in the AWS console, you will see a "Volumne" tab on the left hand side. Detach the volume of the faulty instance and attach with the new instance.
3. Now mount this newly attach drive in the new instance and add a new user into it.
4. Simply now create a new user and set permission that user dont need a .ppk key file to login.

Step 2: Getting root access
1. Once you login with this new user created, you have to simply type "su" command. You will be asked to enter the password of the new user.
2. Enter password and now you will be a root user. You don`t need sudo anymore.

Pseudo-terminal will not be allocated because stdin is not a terminal

Try ssh -t -t(or ssh -tt for short) to force pseudo-tty allocation even if stdin isn't a terminal.

See also: Terminating SSH session executed by bash script

From ssh manpage:

-T      Disable pseudo-tty allocation.

-t      Force pseudo-tty allocation.  This can be used to execute arbitrary 
        screen-based programs on a remote machine, which can be very useful,
        e.g. when implementing menu services.  Multiple -t options force tty
        allocation, even if ssh has no local tty.

---

Related Topics