"Sudo" Fails with "Sudo Requires a Tty" When Executed from Putty Command Line

Sudo fails with sudo requires a tty when executed from PuTTY command line

The sudo requires TTY/interactive session.

On the contrary the PuTTY/Plink -m switch uses non-interactive session by default.

Use the -t switch to override that.

putty.exe -ssh [IP] -l [user] -pw [password] -t -m [Script]

Execute sudo command on Linux from plink.exe on Windows

i know that the question is old but this can help

you can execute plink (putty tools)

plink -v -ssh -m "path/to/commands.txt" -l usertologin -pw PASSWORDSERVER

commands.txt:

echo -e "PASSWORD\n" | sudo -S cat /etc/passwd

sudo -S is to receive the password from stdin and with the echo -e "password\n" is to pass the password (and \n is like to press intro -new line- )

the same way you can execute the passwd command:

> echo -e "OLDPASSWORD\nNEWPASSWORD\nNEWPASSWORD" | passwd

How to pass the password to su/sudo/ssh without overriding the TTY?

For sudo there is a -S option for accepting the password from standard input. Here is the man entry:

    -S          The -S (stdin) option causes sudo to read the password from
                the standard input instead of the terminal device.

This will allow you to run a command like:

echo myPassword | sudo -S ls /tmp

As for ssh, I have made many attempts to automate/script it's usage with no success. There doesn't seem to be any build-in way to pass the password into the command without prompting. As others have mentioned, the "expect" utility seems like it is aimed at addressing this dilemma but ultimately, setting up the correct private-key authorization is the correct way to go when attempting to automate this.

proper way to sudo over ssh

Another way is to use the -t switch to ssh:

ssh -t user@server "sudo script"

See man ssh:

 -t      Force pseudo-tty allocation.  This can be used to execute arbi-
         trary 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.

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.

Executing (sudo) subcommands using Plink

sudo -i && cd /root/docker/storm-supervisor/ && ./stop-all.sh

Try your command in Linux shell. It won't work either. It will execute an elevated shell and wait for you to type commands. Only after you leave sudo shell, it will run the other commands (using the original account).

The cd and ./stop-all.sh are sub-commands of the sudo. So you have to treat them that way.

• Best way is to provide the commands on sudo commandline:

    sudo "cd /root/docker/storm-supervisor/ && ./stop-all.sh"
  

  But that will probably require modifications of the sudoers file. Though it's the right way.

• Or you will need to feed the commands to sudo input:

    echo "cd /root/docker/storm-supervisor/ && ./stop-all.sh && exit" | sudo
  

• Or feed everything to Plink input:

  (
    echo cd /root/docker/storm-supervisor/
    echo ./stop-all.sh
  ) | plink -ssh -l username -pw root username@10.223.26.34 -t sudo -i
  

• Or even:

  (
    echo sudo -i
    echo cd /root/docker/storm-supervisor/
    echo ./stop-all.sh
  ) | plink -ssh -l username -pw root username@10.223.26.34 -t
  

sudo: command not found while using plink

Scripts such as ~/.profile or ~/.bash_profile responsible for setting up the current user's PATH are run only on login shells.

Running sh -c 'somescript' (as performed by ssh host 'somescript') is neither a login shell, nor an interactive shell; thus, it does not gain the benefit of such scripts.

This means that additions to the PATH (in your case, /usr/local/bin) may not be present with commands run in this way.

Among your options:

• Pass the PATH you want as part of the command to remotely run. This might look like:

  plink -ssh user@host "PATH=/bin:/usr/bin:/usr/local/bin /opt/sieb/w44dvftyw/run.sh"
  

• Embed a working value in the script you're running:

  #!/bin/bash
  PATH=/bin:/usr/bin:/usr/local/bin 
  # ...put the rest of your script here.
  

---

Related Topics