← Back to context

Comment by gregw2

2 years ago

Does anyone know any SSH clients that support line-buffering of input?

I.e. where what you type doesn't get transmitted until you hit or click return/send?

I had one of these clients (but for telnet) back in more active MUD gaming days but haven't seen it with the few SSH clients I've used since... but always thought that would be a good defense to SSH keystroke timing data leakage, and potentially superior to this 20ms delay approach mentioned in this article, at least for some usage scenarios.

(Although now that I think about it, ideally you might want it to also transmit when someone hits tab so you could still have linux shell autocomplete...)

6 comments

gregw2

Reply
kelnos  2 years ago

That would only work if the ssh client could know exactly what was going on in the user session. Like, how would that work if I were editing a file with vim? Or even just typing a command into the shell (where I might need to backtrack and edit the command)?

This doesn't seem very feasible or useful to me.

yencabulator  2 years ago

That's more a choice a current-day shell etc does for you, wanting to control the editing experience. Run `cat` and it'll switch to line buffered mode, note how your arrow keys just input line noise, and watch the cat process with ptrace if you want to confirm it really receives the whole line in one read syscall.

jesprenj  2 years ago

mosh is quite smart with this

  • gregw2  2 years ago

    Not exactly what I was looking for in terms of the security side of things but perhaps more sophisticated in terms of the editing handling. Cool, thanks for the reply!

    Money quote from https://mosh.org/#techinfo :

    Remote-shell protocols traditionally work by conveying a byte-stream from the server to the client, to be interpreted by the client's terminal. (This includes TELNET, RLOGIN, and SSH.) Mosh works differently and at a different layer. With Mosh, the server and client both maintain a snapshot of the current screen state. The problem becomes one of state-synchronization: getting the client to the most recent server-side screen as efficiently as possible.

    This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB3 mode. ...

    Roaming with SSP becomes easy: the client sends datagrams to the server with increasing sequence numbers, including a "heartbeat" at least once every three seconds. ...

    Instant local echo and line editing

    The other major benefit of working at the terminal-emulation layer is that the Mosh client is free to scribble on the local screen without lasting consequence. We use this to implement intelligent local echo. The client runs a predictive model in the background of the server's behavior, hypothesizing that each keystroke will be echoed at the cursor location and that the backspace and left- and right-arrow keys will have their traditional effect. But only when a prediction is confirmed by the server are these effects actually shown to the user. (In addition, by default predictions are only displayed on high-delay connections or during a network “glitch.”) Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct.

    Thus, unlike previous attempts at local echo with TELNET and RLOGIN, Mosh's local echo can be used everywhere, even in full-screen programs like emacs and vi.