Well, that's just called "remote echo" and it doesn't have much to do with SSH. It's just that the remote is in charge of drawing the character on the screen if needed.
If you change to "local echo" it would cause problems with programs such as vi which will interpret certain characters (such as hjkl) as special commands and won't actually draw them on the screen.
If you start a remote program that just "eats" your input without updating the terminal (like a password prompt) you won't see the 2nd tcp roundtrip.
You'd have the same behaviour with a serial link, rsh, telnet or anything else.
I think I saw a custom SSH client on hn some months ago that would try to compensate high network latencies by echoing the characters locally while waiting for the remote reply. It would then undo the local echo and use the "authoritative" reply instead.
The article isn't as judgmental as the headline makes it sound. It notes that in practice, it only sends three segments across the wire, and that's what I'd expect from telnet, too.
For a high latency situation if you're text editing there is EMACS TRAMP mode, and probably others similar that buffer the file locally, which will also solve the responsiveness problem.
I think it would be neat if SSH provided an API or a set of special characters so that the remote shell could tell SSH to switch back and forth between remote and local echo. For example, bash could tell SSH to begin local echo mode after it finishes printing the prompt, and end local echo mode when the user enters a key sequence that requires remote processing, like Tab or Return. vim could enter local echo mode when the user enters insert mode and leave when the user presses the Esc or Return, etc.
Perhaps this extra complexity would lead to all sorts of strange bugs though.
Are you thinking of EXTPROC/LINEMODE? There's outstanding patches to bash, telnet, and ssh to support these, which enables local line-editing that works smarter than just local echo.
One interesting thing about this is how it can lead to timing attacks which leak information about your keystrokes. There's a great paper [1] which gives some examples. One more reason to use pubkey authentication for SSH.
I believe that passwords are not transmitted like this in SSHv2 because of that very attack (not to say there are not overwhelmingly good reasons to use public key authentication anyway).
Specifically, the section on "Why not send whole commands" made me wonder who this is targeted at, its pretty basic UNIX stuff to know how an Async ASCII terminal works.
Then, obviously, it's targeted at people who don't know "pretty basic UNIX stuff". Which to a few points of precision is everyone. And, guessing, a significant enough portion (to be interesting article) of HN readers.
you can also use linemode. it works for telnet and, uhm, it sort of work for ssh through a 3rd party patch.
it sends whole commands AND supports everything. That's because its not just a dumb echo, and require terminal support on the server side.
mosh actually does something in between (and thus have display errors sometimes)
it's hardly surprising that you send one packet, get one ack and then, when the shell wants to update the display sends a packet and then gets one ack. how should it be different? (leaving aside udp-protocols for similar functionality as mosh)
Correct, UDP doesn't ACK, but you also don't know if the packet reached the server for the same reason. UDP is great for streaming data that may arrive out of order or where packets can be lost and it isn't critical, such as streaming video, but it is awful if you need to be sure the data got to its destination.
[+] [-] simias|13 years ago|reply
If you change to "local echo" it would cause problems with programs such as vi which will interpret certain characters (such as hjkl) as special commands and won't actually draw them on the screen.
If you start a remote program that just "eats" your input without updating the terminal (like a password prompt) you won't see the 2nd tcp roundtrip.
You'd have the same behaviour with a serial link, rsh, telnet or anything else.
I think I saw a custom SSH client on hn some months ago that would try to compensate high network latencies by echoing the characters locally while waiting for the remote reply. It would then undo the local echo and use the "authoritative" reply instead.
[+] [-] pronoiac|13 years ago|reply
[+] [-] robinson-wall|13 years ago|reply
[+] [-] notaddicted|13 years ago|reply
[+] [-] jdonahue|13 years ago|reply
Perhaps this extra complexity would lead to all sorts of strange bugs though.
[+] [-] ephemient|13 years ago|reply
TIOCPKT_IOCTL(EXTPROC) and TIOCSIG support landed in Linux kernel 2.6.36: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] toki5|13 years ago|reply
I had to write an SSH terminal inside a browser, and it was full of "why the heck did they"s followed ten minutes later by "oh, that's why"s.
[+] [-] gcr|13 years ago|reply
[+] [-] msmith|13 years ago|reply
[1] http://users.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf
[+] [-] betterunix|13 years ago|reply
[+] [-] M4v3R|13 years ago|reply
[+] [-] Aloha|13 years ago|reply
Specifically, the section on "Why not send whole commands" made me wonder who this is targeted at, its pretty basic UNIX stuff to know how an Async ASCII terminal works.
[+] [-] njharman|13 years ago|reply
[+] [-] zobzu|13 years ago|reply
mosh actually does something in between (and thus have display errors sometimes)
[+] [-] ibotty|13 years ago|reply
[+] [-] quackerhacker|13 years ago|reply
[+] [-] chinpokomon|13 years ago|reply
[+] [-] antocv|13 years ago|reply
[+] [-] chinpokomon|13 years ago|reply
[deleted]
[+] [-] inopinatus|13 years ago|reply
[+] [-] shafferj|13 years ago|reply