Is there a way to avoid SSH typing delay?

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.

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

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.

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.

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. And (as it just wraps around your system ssh client) there is no danger of not keeping up with ssh security fixes.

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!

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

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.

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

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

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\'