# Is there a way to avoid SSH typing delay?

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

• 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
• mosh.mit.edu – alfC Oct 2 '14 at 21:43
• @mailq don't you use 3G in 2019? sshing from the village country house or underground is more like doing it with dialup – POMATu Jul 30 '19 at 14:00
• Contrary the answers, the extensive usage of tc (traffic shaping) functionality of the linux kernel could help a lot. But it requires some doc digging to configure it correctly. – peterh Feb 6 '20 at 14:27

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

• 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 '16 at 6:36
• Look at the Mosh paper. The author did some benchmarking mosh.org/#techinfo – user7610 Sep 12 '16 at 10:24
• I've had to use "ssh -t .... bash -i" -t means 'force pty allocation' (else, SSH doesn't believe it has to and bash complains) and -i runs bash in interactive mode (else, it skips some initialisation). Passing ssh -C too (compress traffic) can help further. Great advice anyway, thanks. – zakmck Nov 15 '19 at 17:51

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.

• You can install it on a local directory from source without sudo. Also, go look at mosh.org. It says, "No privileged code. No daemon. You don't need to be the superuser to install or run Mosh. The client and server are executables run by an ordinary user and last only for the life of the connection." – Steven C. Howell Aug 25 '16 at 1:43
• Just to note. Mosh is not SSH. It uses it's own proprietary protocol. (I don't have a problem with that, though.) – user7610 Sep 12 '16 at 10:28
• This worked from scratch for me on android and home bad wifi network. It knows about readline – Tinmarino Aug 4 '18 at 19:12
• @user7610 is it proprietary? It's on github in entirety and open licensed afaik.. Did i miss anything? It does have its own protocol based on UDP and protobuf, but that seems entirely open as far as I can tell, but maybe i missed something – Alex Apr 12 '20 at 11:06
• @Alex The protocol is related to a single project which has complete control of it and there is only a single implementation of it. That is what I meant by saying "proprietary". Open licensed is nice, but until there are at least three independent but inter-operating implementations, and preferable an IETF RFC ;) I'll call it that. Using Mosh does not bring the usual burdens associated with replacing standard protocols with nonstandard; the switch is seamless, except for using UDP (which is a feature, we want to use udp for remote terminal), so I am not bothered by it. – user7610 Apr 12 '20 at 12:46

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.

• This should be the accepted answer – Freddie Fabregas Feb 28 '19 at 13:15
• I failed to install PuTTY on macOS, is there a replacement? – Aero Windwalker May 16 '19 at 5:06
• Putty on linux is a bit pain. It can't reconnect automatically, shows some message box on disconnect and I need to open window again. I wish I could use something like kitty or plink.exe on linux or better to just tweak autossh somehow. Some devices don't support mosh tho (if I trying access my home openwrt router) – POMATu Jul 30 '19 at 13:57

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.

• 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
• When I do this it just stops there and doesn't connect, neither gives any error messages – aderchox Jul 28 '20 at 22:37
• what is rlfe ? – alper Aug 9 '20 at 20:54
• @aderchox try typing ls, you will see that you are actually connected. – Dan Bolser Mar 15 at 14:00

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

(2020 update)

Ridiculous as it sound I found that installing TigerVNC and then launching a remote terminal and "streaming" screen through VNC protocol offers a much better experience, and remove the lags even on no-so-good connections.

• is TigerVNC free to use? – alper Aug 19 '20 at 1:40
• @alper: yes, you can install for free on any Linux and create as many virtual desktops per machine as you like (normally one per user). Look at github.com/earizon/tigervnc_remote_desktop for an (opinionated) way to use it. – earizon Aug 20 '20 at 11:59

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 multiplexed 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.
•  master / shared ssh connections link is dead – alper Aug 9 '20 at 22:19

This does what you want. You need to install both the client and the server though, and the OpenSSH upstream never adopted the changes. https://github.com/hyc/OpenSSH-LINEMODE

• Anyone who installs this in 2020 will be instantly pwnd, since it hasn't had any security updates in 10 years :o – hopeseekr Dec 20 '19 at 19:01

You can use tmux to achieve a fluent echo of your typing. Run tmux locally. If you have the ssh shell in one pane, and a local shell in a pane below it, then from the local pane you can send keys to the remote pane.

tmux send-keys -t top 'ls' C-m


Interactive commands and small commands I type directly in the lagging ssh shell. As soon as the lag starts to hinder my typing, I switch to the local pane and use send-keys. This works even in the middle of typing a command.

To shortcut it I added this to my .bashrc

function ts {
args=$@ tmux send-keys -t right "$args" C-m
}


Thanks to Christian Pelczarski for explaining send-keys: https://minimul.com/increased-developer-productivity-with-tmux-part-5.html

You will have to escape when using quotes, for example

ts git config --global alias.lola \'log --graph --decorate --pretty=oneline --abbrev-commit --all\'

• Another option in tmux would be to use synchronize-panes to make two panes (one local, one remote) receive the same keystrokes. – Evgeny Mar 3 '20 at 13:17