Is there a way to avoid SSH typing delay?

Question

Can I tell SSH to send the data only after pressing enter or tab, and not after each individual keypress?

Answer 1

No, because SSH has no way of knowing whether what you're typing would require an enter or tab to action -- if you're trying to go through your command history, for instance, the ^R or up arrows wouldn't be sent by themselves, and that would be... unpleasant.

You don't have to wait between each character for it to appear on the screen, though; if you know what you have to type, bash away at it as quick as you like, and the terminal will catch up in about one round-trip time from when you stopped typing, which is about as good as you'll get out of a line-buffered setup anyway (packet loss is different, but it introduces it's own interesting quirks).

Answer 2

You can emulate that behaviour if you're just running commands by doing,

ssh user@targetmachine 'my commands in a string'

but,

1. this adds an additional delay in creating the connection (can be mitigated using master / shared ssh connections)
2. if you don't have a passwordless private key you're going to have to use ssh-agent or type the password in
3. clearly it doesn't work if you're interacting with menus or editing files, etc.

Answer 3

Open the ssh session with ssh host.example.org bash (or whatever shell you want to use).

You will get line-buffered mode to the remote shell, which means that you will not get a prompt and line-editing but you will get local echo and "one line at a time" mode. It is sometimes useful when working with a very bad connection. Not all programs will run properly because you will not have a pseudo-tty but most UNIX utilities work just fine.

Update:

When using the above trick you can get normal line editing (readline) at the local end by using a convenient wrapper program called rlfe. Just run rlfe ssh host.example.org bash.

Answer 4

PuTTY offers two features that may be of use: "local echo" and "local line editing". Local line editing buffers everything and only sends it to the server after a line return. That can make the command line much easier to deal with, but it may also make using a text editor hell.

PuTTY also has some other options for enabling / disable certain things (Nagle's algorithm) that may affect perceived connection latency. As I see it, the OpenSSH client doesn't offer all the features that PuTTY does in this regard, and I don't know of a Linux alternative that compares.

Otherwise, womble has it right.