Since this is a problem associated with ssh itself, you’ll more than likely be able to reproduce the problem on Linux, FreeBSD, macOS and Cygwin’s Unix services on Microsoft Windows. Fortunately, the fix should be pretty much the same on all of these platforms.
Method 1: Finding a Terminal for ssh
While you’re more than likely already working from a terminal, ssh probably doesn’t realize this. It might still be trying to look for a TTY terminal emulator in spite of the fact that you’re inside of a command prompt window. Try reproducing the error to test this. We configured a virtual machine to serve as an example and ran ssh user@linuxtest.example ‘sudo /var/mail/startup.sh’ as a test. Naturally, you’ll want to change the command and ssh line to something that matches what you’re trying to do.
You’ll want to ensure that you’re logging into the server that you thought you were. Regardless, check to see if you still receive the sudo: no tty present and no askpass program specified error message. More than likely, if you’re still receiving it then you’ll see it three times and possibly even get prompted to enter your password the way you would have if you running sudo locally on Debian or Ubuntu. Try adding -t after ssh to correct your syntax error. Nine times out of ten this will force ssh to allocate a virtual TTY to itself and pretend that it happens to be running inside of a real terminal. You don’t have to change anything else about your command. Simply add the -t option after the letters ssh and then keep the host and passed command the same. You’ll also want to keep this in mind if you ever have to run ssh in the latter part of your command. For instance, if you were getting this same sort of error when running a command that was formatted as ssh -t user@linuxtest.example ‘ssh user@linuxtest2.example’ you would have to keep the -t option after the first ssh to prevent it. Note that if you later changed the second command to either produce or consume data, then you wouldn’t want to use -t at all. For instance, if you started running cat instead of a script then you could dump the -t since you wouldn’t need to allocate a terminal for that.
Method 2: Patching the visudo File
You may also have a configuration problem that produces this error. Modify the visudo file by issuing the sudo visudo command, and keep in mind that you’ll never want to edit this file any other way. You should find a line that features ALL = NOPASSWD in it followed by the types of commands that you don’t need to enter the administrator’s password to run. Each individual command needs to end with a comma except for the last one on the line. Thus if you had something that read like /sbin/poweroff /sbin/start /sbin/stop it will treat these all as a single command and throw the error at you. Likewise, if you’re missing a command that you’re trying to run via ssh then you’ll get this error too. Make the necessary adjustments and save the file before checking if the error is still reproducible. Should you still have the error even after doing so and restarting the service, then try the following command in the image below and make sure that the PermitTTY line features the word yes after it. If this is the last line in your file, then make sure that there’s a blank newline afterward. GNU nano performs this task automatically by default.
You’ll need to restart any relevant services before attempting to again reproduce the error message.
How to Fix ‘sudo apt-get command not found’ on macOSFix: sudo command not foundBug Which Caused Action Center to Momentarily Appear on the Left Still Present…Fix: “The tag present in the reparse point buffer is invalid” on OneDrive
