Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
I'm very interested where you have such a typing delay that you can't work with it. I used ssh in the modem age and never faced these issues. – mailq Aug 18 '11 at 13:52
I'm accessing a SliceHost VPS (USA) from Belgium. The delay is noticable enough to make me confused. However, I've noticed that other people seem to be less bothered by this than I am.. – StackedCrooked Aug 18 '11 at 15:26
3 – alfC Oct 2 '14 at 21:43
up vote 17 down vote accepted

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).

share|improve this answer
I would be really interested in finding a way to benchmark the ssh-typing-speed across several machines. I observed that the speed can vary a LOT between machines located in the same place and that do not have any heavy load on them. My theory is that this happens especially with the small instances from AWS (like micro or mini ones). – sorin Jul 12 at 6:36

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.

share|improve this answer

Mosh was designed to address this exact issue. It is designed for use over high-latency and unreliable connections, and provides local echo and line editing.

share|improve this answer

Open the ssh session with ssh 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.


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 bash.

share|improve this answer
I tried and didn't find it very workable. But it's cool to know, thanks. – StackedCrooked Aug 18 '11 at 17:27
this works wonderfully for me. – lakesare Dec 29 '15 at 0:17

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

ssh user@targetmachine 'my commands in a string'


  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.
share|improve this answer

Having had the same issue (high latency and packet loss due to terrible mobile data quality at some locations), and mosh not cutting it for me (it needs special programs on all remote hosts, fixing UTF8 locally and remotely on all servers without breaking them, modifying all the firewalls - and it doesn't really provide local line editing anyway) I've decided to write a small wrapper to provide local line editing mode for ssh.

By default, it just passes everything to ssh in default char-by-char mode, but you can press a hotkey to enter readline-powered local line editing mode at any time. So you could enter (with editing, command recalling etc) whole line locally, and then when you press enter it will be sent as one TCP packet to remote side.

Advantage is lag-free command line editing (like old telnet cooked/canonical "line-by-line buffered mode", but with superior editing commands provided by GNU readline). Also, nothing needs to be changed on servers or firewalls. And editors and other curses-based programs continue to work normally (albeit with lag) in default char-by-char mode as in normal ssh connection.

Disadvantage is you either need to press hotkey to enter local line editing mode every time you want it, or you need to modify prompt on remote host to allow autodetection. Also, remote tab filename completion currently works only by dropping you back to char-by-char mode (or uses local filesystem instead of remote one, depending on your preferences). It's work in progress, though, so pull requests or workable ideas for improvement are welcome!

On the unconventional side, you could alternatively use SSHFS to mount remote filesystem locally.

The advantage is not only that your shell (and its line editing) is local and lag-free, but also that you can navigate remote filesystem and use shell filename completion (tab key) for remote files. Also, (the best feature IMHO) you can use your local editor of choice for lag-free editing of remote files.

Disadvantages are (especially if you link is also low-bandwidth, and not only high-latency) that for each file to be edited, it needs to be fully transfered to localhost, and then after edit, fully transfered to remote again. SSHFS does provides for some caching (see sshfs(1) options cache, cache_timeout, cache_x_timeout) to alleviate that problems somewhat. Also, if you want to execute something on remote you need to use another screen or prefix all commands with "ssh remotehost" (for example ssh remotehost sudo service apache restart). See option ControlMaster in ssh_config(5) to make that faster to execute (and without password prompting).

share|improve this answer

Your Answer


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.