- When aliasing ssh to 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 ^M when 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.
- There is also the risk that programs will assume they can render output that is not friendly for file redirection. Normally if you were to redirect STDOUT to a file, the program would recognize that your STDOUT is not a terminal and omit any color codes. If the STDOUT redirection is from the output of the ssh client and the there is a PTY associated with the remote end of the
client, the remote programs cannot make such a distinction and you will end up with terminal garbage in your output file. Redirecting output to a file on the remote end of the connection should still work as expected.
Here is the same bash test as earlier, but for STDOUT:
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.
Aliasing ssh to 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.