Linux ssh no tty

Rsync over SSH getting no tty present

I have added a .hushlogin to the backups user on the remote box and confirmed that I can ssh as backups using a key to the remote box with nothing displayed (login is hushed). I still get these messages. Note that I can ssh as backups to the remote box using a key successfully. Note that my sudo does not have the -tt option. Note that the following is set in source and destination’s /etc/sudoers file:

backups ALL= NOPASSWD:/usr/bin/rsync 

4 Answers 4

Sometimes you think too hard about things.

Rsync was not installed on the remote system.

Putting this here so I can remember & share this trick:

rsync -av -e "ssh -tt" --rsync-path="stty raw -echo; sudo /usr/bin/rsync" user@$:/ $

This method seems to bypass the requirement for a tty as enforced on some system’s default /etc/sudoers file with Defaults requiretty . This information was crafted after reviewing this SO question & answers.

In that answer, they recommend removing Defaults requiretty from /etc/sudoers . This is the easier method. However, if you are unable to modify the remote host /etc/sudoers to remove this configuration option, you can try forcing the local rsync to use ssh -tt . This option for ssh is described in the ssh client manual page like this:

Force pseudo-terminal 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.

Thus, we force ssh to allocate a pseudo-tty to avoid the error:

Pseudo-terminal will not be allocated because stdin is not a terminal. stty: standard input: Inappropriate ioctl for device sudo: sorry, you must have a tty to run sudo 

Then, the —rsync-path is overridden with a command to do the following:

stty raw -echo; sudo /usr/bin/rsync 

stty raw -echo is to set the line discipline of the remote terminal as pass through. This effectively causes it to behave like a pipe that would be used instead of a pseudo-terminal without -tt .

Then the remote rsync command will be sudo /usr/bin/rsync , which now has a pseudo-tty and will pass the requiretty check for sudo .

Источник

Using SSH Without A TTY

I recently received a mail asking how to get SSH to work from within a reverse shell (see php-reverse-shell , php-findsock-shell and perl-reverse-shell ). I thought I’d write a brief description of the problems I’ve seen and how to work round them.

I’d be very interested if anyone has any better solutions. Drop me a mail (pentestmonkey at pentestmonkey dot net).

Update: Also see this follow-up post on a similar subject.

Problem 1: “Host key verification failed.”

When you connect to a host for the first time you normally (when you ave a TTY) get a message like:

The authenticity of host 'localhost (127.0.0.1)' can't be established.

Are you sure you want to continue connecting (yes/no)?

You can answer “yes” and the authentication proceeds.

However, if you don’t have a TTY (like when you’re using a reverse shell), authentication fails immediately with an error:

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

Host key verification failed.

Workaround

Before attempting an SSH connection for the first time you need to grab the host keys for host you want to connect to and store them in the known_hosts file of the current user:

ssh-keyscan -t rsa1,rsa,dsa localhost >> ~/.ssh/known_hosts

Next time you try an SSH connection you won’t get the “Host key verification failed” error.

Problem 2: Can’t enter SSH password

If you don’t have a TTY (you typically don’t when using a reverse shell) you won’t be asked for a password, authentication will just fail:

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

Permission denied (publickey,keyboard-interactive).

Workaround

You can use an external program to provide the password you want to use. Check out:

$ cat /tmp/returnpassword.sh #!/bin/sh echo 'some password'
Other potential solutions
Modify your php-reverse-shell (or whatever) to use PTYs if the PHP installation supports them. Of course your php code will also need to handle the case when PTYs aren’t supported. PHP 5 can support PTYs, but it needs to be compiled with the right options (–enable-pty). The code modification should be simple:
$descriptorspec = array( 0 => array("pty"), // stdin 1 => array("pty"), // stdout 2 => array("pty") // stderr );
 
The system I tested the above code on gave the following error because PHP5 didn’t have PTY support enabled:
 
Warning: proc_open() [function.proc-open]: pty pseudo terminal not supported on this system in . htdocs/php-reverse-shell.php on line 109
 
Источник
 
sudo over ssh: no tty present and no askpass program specified
 
I keep getting this error and have tried several ways discussed online to fix this and none are working for me. I have setup SSH keys so when I run 'ssh newton@host.com' it automatically logs me in, I have also set this user in visudo to be 'newton ALL=(ALL:ALL) ALL' I then also tried to add 'newton ALL=NOPASSWD: /var/www/script.sh' Unfortunately, every time I run ssh newton@host.com 'sudo /var/www/script.sh' from Cygwin I get back. I have also tried to add -t -t but then it prompts me for the password.
 
total size is 21209180 speedup is 314.69 sudo: no tty present and no askpass program specified Sorry, try again. sudo: no tty present and no askpass program specified Sorry, try again. sudo: no tty present and no askpass program specified Sorry, try again. sudo: 3 incorrect password attempts sudo: no tty present and no askpass program specified Sorry, try again. sudo: no tty present and no askpass program specified Sorry, try again. sudo: no tty present and no askpass program specified Sorry, try again. sudo: 3 incorrect password attempts 
 
This is not specific to Cygwin; I see the same problem using ssh example.com sudo echo hello from one Linux system to another. I've updated your title accordingly. I've also flagged your question for migration to the Unix site.
 
8 Answers 8
 
You need to have a terminal available to run sudo so that it can prompt you for the password. If you pass a command to ssh , it assumes that the command doesn't need a terminal and doesn't create one, unless you pass -t . See SSH inside SSH fails with "stdin: is not a tty" for a more detailed explanation.
 
If you aren't able to enter the password even with -t , it's possible that your problem is due to Windows. The Windows console does not completely emulate a unix terminal; there may be some difficulty for Cygwin applications to properly emulate a terminal in these circumstances (I'm not sure about that, note). If that's the problem, run ssh inside a terminal emulator such as Console2 or Mintty (included in the Cygwin distribution) — see Best way to use a shell with Cygwin in Windows 7.
 
If you expected the SSH passphrase to replace your password for authentication to sudo, that's not going to happen. Sudo requires a password (unless you add the NOPASSWD tag in the sudoers file). Note that you still need to have a terminal, even with NOPASSWD , if the requiretty option is set in the sudoers file.
 
If you want passwordless login up to the root account (which is generally not a good idea from a security perspective), use SSH to reach the root account, preferably in two hops. See SSH inside SSH fails with "stdin: is not a tty" (with root@host.com for otheruser@computertwo.com ).
 
Источник
 
SSH error when executing a remote command: "stdin: is not a tty"
 
I'm trying to connect to machine one with ssh and then connect to another machine two with ssh. But get this error:
 
ssh user@computerone.com 'ssh otheruser@computertwo.com' stdin: is not a tty 
 
Try adding -t flag to first ssh . By the way, since your question is not related to programming, it might be more appropriate at superuser.com
 
1 Answer 1
 
When logging into a shell, the remote host assumes that the connection is done by a human user. Therefore, it is reasonable to expect that they have control over the standard in on the client. That is to say, the user is giving input on a terminal through the keyboard. If the remote host detects that the user is not human (because the input is not a terminal - tty, but another process), it may warn the user about this unexpected condition.
 
A demonstration of the discussed misbehavior and how to avoid it ( man ssh and look for -t for a more thorough explanation).
 
$ ssh -t genja.org 'ssh raptor.lan hostname\; uptime' host: genja.lan raptor 21:17:27 up 3 days, 15 min, 1 user, load average: 0.00, 0.00, 0.00 Connection to genja.org closed. $ ssh genja.org uptime host: genja.lan 21:17:43 up 12 days, 17:40, 1 user, load average: 0.30, 0.08, 0.02 
 
$ ssh genja.org 'ssh raptor.lan hostname\; uptime' host: genja.lan Permission denied (publickey,keyboard-interactive). 
 
You may want to make a tunnel instead:
 
ssh -L 4444:raptor.lan:22 genja.org 
 
Then, on a different terminal:
 
ssh -p 4444 localhost will give you a conenction straight to "raptor.lan" 
 
Use IP addresses such as 192.168.0.11 if DNS aliases are not configured on the remote end.
 
Источник