Is there a way to avoid SSH typing delay?
Solution 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).
Solution 2:
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.
Solution 3:
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.
Solution 4:
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.
Solution 5:
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).