How to fix stdin: is not a tty in SSH

The message is often just a harmless warning. If your remote command runs fine and produces correct output, you can ignore it. Only force a TTY when a remote program genuinely needs one (interactive prompts, top, editors, tools that call tcgetattr).

To silence the warning for a non-interactive command without allocating a TTY, you can explicitly disable PTY allocation:

ssh -T user@host 'your-command'

When a remote command truly requires an interactive terminal, force pseudo-terminal allocation with -t:

ssh -t user@host 'your-command'

If SSH itself has no local TTY (for example, you are already inside a pipe or a script), a single -t is not enough. Use -tt to force allocation regardless of the local stdin state:

ssh -tt user@host 'interactive-command'

When piping a local script to a remote shell, name the interpreter explicitly so there is no ambiguity, and do NOT force a TTY (a PTY would merge stdout/stderr and echo input, corrupting script output):

ssh user@host 'bash -s' < /path/to/local_script.sh

This streams the local file into the remote bash over stdin and runs without a terminal, which is exactly what a non-interactive script wants. Reserve -t/-tt for scripts that must drive an interactive program.

If .bashrc or .profile runs a command that needs a terminal (like mesg y or stty), wrap it in a TTY check so it only runs in interactive sessions:

# Original (prints "stdin: is not a tty" in non-interactive SSH)
mesg y

# Fixed (only runs when stdin is a terminal)
if [ -t 0 ]; then
    mesg y
fi

This lets your startup files work in both interactive and non-interactive SSH sessions. This is the single most common real fix when the warning appears on every non-interactive connection.

When you pipe data into a remote command, specify a command that consumes stdin and leave the TTY off. Forcing -t here is wrong: with a PTY, the remote stdin becomes the terminal rather than your pipe, so the piped data may not reach the command.

# Triggers the warning (implicit command + redirected stdin)
echo 'data' | ssh user@host

# Correct: name a command that reads stdin (no -t)
echo 'data' | ssh user@host 'cat > /tmp/file.txt'

Do NOT try to feed a sudo password this way. A command like echo 'password' | ssh -t user@host 'sudo -S cmd' does not work (with -t the pipe is no longer the remote stdin) and exposes the password in your shell history and process list. Instead, configure passwordless privilege for the specific command on the remote host with a tightly scoped sudoers rule:

# On the remote host, e.g. /etc/sudoers.d/deploy (edit via 'sudo visudo -f')
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

Then run it over SSH with no password and no TTY:

ssh user@host 'sudo systemctl restart myapp'

If an interactive password prompt is genuinely required, run ssh -t user@host 'sudo cmd' and type the password at the prompt rather than piping it.

In automation, this warning around Git usually means the SSH key is not loaded, not that a TTY is missing. Configure the agent and a non-interactive host-key policy instead of forcing a terminal:

# Start the agent and load the deploy key
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# Avoid the interactive host-key prompt safely by pinning the key
ssh-keyscan github.com >> ~/.ssh/known_hosts

Git invokes ssh itself and does not need a TTY for git clone/fetch/push, so adding -t is unnecessary and can break the transport. Pinning the host key with ssh-keyscan is preferred over StrictHostKeyChecking=no, which disables host verification.