Every once in a while I will do something like
ssh user@host sudo thing
and I am reminded that ssh doesn't allocate a pseudo-tty by default. Why doesn't it? What benefits would I be losing if I aliased
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
The primary difference is the concept of interactivity. It's similar to running commands locally inside of a script, vs. typing them out yourself. It's different in that a remote command must choose a default, and non-interactive is safest. (and usually most honest)
Ctrl-cbreak would normally cause a loop on the ssh command to break immediately, your control sequences will instead be sent to the remote server. This results in a need to "hammer" the keystroke to ensure that it arrives when control leaves the ssh command, but before the next ssh command begins.
I would caution against using
ssh -t in unattended scripts, such as crons. A non-interactive shell asking a remote command to behave interactively for input is asking for all kinds of trouble.
You can also test for the presence of a terminal in your own shell scripts. To test STDIN with newer versions of bash:
# fd 0 is STDIN [ -t 0 ]; echo $?
ssh -t, you can expect to get an extra carriage return in your line ends. It may not be visible to you, but it's there; it will show up as
^Mwhen piped to
cat -e. You must then expend the additional effort of ensuring that this control code does not get assigned to your variables, particularly if you're going to insert that output into a database.
Here is the same bash test as earlier, but for STDOUT:
# fd 1 is STDOUT [ -t 1 ]; echo $?
While it's possible to work around these issues, you're inevitably going to forget to design scripts around them. All of us do at some point. Your team members may also not realize/remember that this alias is in place, which will in turn create problems for you when they write scripts that use your alias.
ssh -t is very much a case where you'll be violating the design principle of least surprise; people will be encountering problems they do not expect and may not understand what is causing them.
One advantage that hasn’t been mentioned in the other answers is that when operating without a pseudo-terminal, the SSH escape characters such as
~C are not supported; this makes it safe for programs to transfer binary files which may contain these sequences.
Copy a binary file using a pseudo-terminal:
$ ssh -t anthony@remote_host 'cat /usr/bin/free' > ~/free Connection to remote_host closed.
Copy a binary file without using a pseudo-terminal:
$ ssh anthony@remote_host 'cat /usr/bin/free' > ~/free2
The two files aren’t the same:
$ diff ~/free* Binary files /home/anthony/free and /home/anthony/free2 differ
The one which was copied with a pseudo-terminal is corrupted:
$ chmod +x ~/free* $ ./free Segmentation fault
while the other isn’t:
$ ./free2 total used free shared buffers cached Mem: 2065496 1980876 84620 0 48264 1502444 -/+ buffers/cache: 430168 1635328 Swap: 4128760 112 4128648
This is particularly important for programs such as
rsync which use SSH for data transfer. This detailed description of how the SCP protocol works explains how the SCP protocol consists of a mixture of textual protocol messages and binary file data.
It’s worth noting that even if the
-t flag is used, the OpenSSH
ssh client will refuse to allocate a pseudo-terminal if it detects that its
stdin stream is not a terminal:
$ echo testing | ssh -t anthony@remote_host 'echo $TERM' Pseudo-terminal will not be allocated because stdin is not a terminal. dumb
You can still force the OpenSSH client to allocate a pseudo-terminal with
$ echo testing | ssh -tt anthony@remote_host 'echo $TERM' xterm
In either case, it (sensibly) doesn’t care if
stderr are redirected:
$ ssh -t anthony@remote_host 'echo $TERM' >| ssh_output Connection to remote_host closed.
On remote host we have to do with this setting:
/etc/sudoers ... Defaults requiretty
$ ssh -T user@host echo -e 'foo\\nbar' | cat -e foo$ bar$
And with sudo
$ ssh -T user@host sudo echo -e 'foo\\nbar' | cat -e sudo: sorry, you must have a tty to run sudo
With sudo we get the extra carriage return
$ ssh -t user@host sudo echo -e 'foo\\nbar' | cat -e foo^M$ bar^M$ Connection to localhost closed.
The solution is to disable the translate newline to carriage return-newline with
$ ssh -t user@host stty -onlcr\; sudo echo -e 'foo\\nbar' | cat -e foo$ bar$ Connection to localhost closed.
Think about backward-compatibility.
The 2 primary modes of ssh are interactive-login with a tty, and specified-command without a tty, because those were the exact capabilities of
rsh respectively. ssh needed to provide a superset of
rsh features to be successful as a replacement.
So the defaults were decided before ssh was born. Combinations like "I wanna specify a command and get a tty" had to be accessed with new options. Be glad that at least we have that option now, unlike when we were using
rsh. We didn't trade away any useful features to get encrypted connections. We got bonus features!
-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.
This allows you to get a "shell" of sorts to the remote server. For servers that do not grant shell access but allow SSH (i.e, Github is a known example for SFTP access), using this flag will cause the server to reject your connection.
The shell also has all your environmental variables (like
$PATH) so executing scripts generally needs a tty to work.