Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Using ssh -t instead of ssh for connections to remote servers has several advantages. For example, I can directly edit a file with vim: ssh -t host vim foo.txt, which would fail otherwise.

Are there any circumstances under which allocating a (pseudo)-tty would be a bad thing when using ssh?

share|improve this question

4 Answers 4

up vote 8 down vote accepted

When piping the input or getting the input back, which is the typical use of "ssh host command". Control characters could be interpreted by the TTY layer (^S for ex.)

share|improve this answer

Yes, sometimes you want to make a silent, backgrounded connection, for example when setting up a tunnel (e.g. SOCKS proxy). In such examples, you want the process to NOT have a tty.

Here's an example of setting up port forwarding from localhost to some remote host...

ssh -l username -fNTL 8073:server:873

After this has been set up, you can then rsync to localhost, instead of to the remote host, hence effectively, tunneling your rsync via ssh...

rsync --port=8073 -a me@localhost::myStuff /tmp/myStuff/

You'd do this say if rsync going out to server was blocked, but ssh wasn't.

share|improve this answer
    
Thanks, this was right too, but I voted the other as it was a more serious issue I overlooked. –  Alex Jurkiewicz May 29 '09 at 12:41

In addition to the above...

(1) Different tilda escape handling:

The "~." escape will disconnect you if you have a pty (-t). For a long-running command, you might want to prevent someone from accidentally halting the process if they type ~.

$ ssh hostname.tomontime.com -t sleep 60
[type ~. and it disconnects]
Connection to hostname.tomontime.com closed.

$ ssh hostname -T sleep 60
[I type ~. and it treats it like normal keystrokes, which the sleep command ignores.]
~.
~.

Try the same thing with CTRL-C. You'll see that with -t you are sending the CTRL-C to the "sleep". With -T you are sending the CTRL-C to the ssh program running on your machine. There may be times when this makes a difference (i.e. the program handles INT differently than HUP)

(2) You just want to minimize the pty or network connection activity.

When trying to reboot a machine that is out of ptys you don't want to encourage the system to try to allocate a pty! This also minimize the network connections that will have to be closed (delaying the reboot).

This will work faster and more reliably:
ssh -T hostname reboot

This may have problems:
ssh -t hostname reboot

share|improve this answer

ssh -t creates a pseudo terminal on the remote machine. This is useful if you are chaining ssh commands thru multiple servers and want a real terminal on the far side (so you could use 'vi' for example).

You might NOT want '-t' when login scripts behave differently if there is a terminal. This is bad practice IMHO, but I've seen cases where a login script checks for TTY before 1) setting the prompt, and 2) expanding the path to many interactive applications.

In another instance (mentioned by TomOnTime above), I actually have run into cases where all the TTY (ptys) are used up. Obviously a mis-configuration, but no need to chew up a resource for a bunch of tunnels and rsyncs.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.