Ssh Error When Executing a Remote Command: "Stdin: Is Not a Tty"

SSH error when executing a remote command: stdin: is not a tty

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

...and the error:

$ 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.

stdin: is not a tty when running 'git push' - github over ssh

thank you to @torek who gave me a way to get more detailed debugging logs GIT_TRACE=1 git push

This has narrowed down the issue to be from Git-LFS, instead of GIT/Github/GitBash.

I have fixed it by running:
git lfs update --force as normal update was coming back with conflict errors

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.

docker run -it over ssh: the input device is not a TTY

SSH does not set up a TTY by default when an explicit command is passed on the argument list (as opposed to when running a remote interactive shell as a default operation). To work around this, add -tt:

$ ssh -tt vagrant@127.0.0.1 -p 2222 "docker run -ti ubuntu:xenial echo hi"

A single -t will set up a remote TTY if and only if a local TTY is present; -tt does so unconditionally.

The RequestTTY option can also be set explicitly, either on the command line:

$ ssh -o 'RequestTTY force' vagrant@127.0.0.1 -p 2222 \
>   'docker run -ti ubuntu:xenial echo hi'

...or in ~/.ssh/config:

Host vagrant
    HostName 127.0.0.1
    Port 2222
    User vagrant
    RequestTTY force

...used as:

ssh vagrant 'docker run -ti ubuntu:xenial echo hi'

---

Quoting the man page for ssh:

-t - 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.

Quoting the ssh_config man page:

RequestTTY - Specifies whether to request a pseudo-tty for the session. The
argument may be one of: no (never request a TTY), yes
(always request a TTY when standard input is a TTY), force
(always request a TTY) or auto (request a TTY when opening a
login session). This option mirrors the -t and -T flags for
ssh(1).

---

Related Topics