Run sole cat. The behavior of your tty is now kinda as you want: you can edit a line and cat will read it only upon Enter or Ctrl+d. This is because your shell configures your local terminal accordingly. When cat exits, the shell configures the terminal back to what the shell needs.
Interactive ssh (that allocates a tty on the remote side) is different. The shell still acts like with cat, but ssh itself configures the terminal to raw. See this question+answer pair of mine to get some insight why interactive ssh wants the local terminal to be raw.
A poor man's solution is to pipe cat to ssh -tt …. IMO this has too many downsides and it's way better to solve the problem without cat.
You want your local terminal to be somewhat cooked when using interactive ssh. For this you can use stty to change the settings of your local terminal. The problem is you need to do this after ssh configures the terminal to raw. If you do this before then ssh will simply override your settings. So you need to give ssh some time and run stty when ssh runs.
You may be tempted to do like (sleep 10; stty …) & ssh …. This won't work, stty will get SIGTTOU and be stopped. A background process cannot reconfigure its own controlling terminal. The easiest way is to run stty in another terminal (i.e. under another controlling terminal) and tell it to target the first terminal.
Proceed like this:
In a terminal where you are going to run ssh, invoke tty and notice what device the terminal is. The output will be like /dev/tty3 or /dev/pts/3.
Run ssh there. Wait until you are logged in.
In another terminal run stty with stdin redirected to the first terminal and with options that will give you "local line editing". Assuming the output from tty was /dev/pts/3, the basic command is:
</dev/pts/3 stty icanon icrnl opost onlcr echo echoe echok
Notes:
The local line will be sent to the remote side only after you hit Enter or Ctrl+j or Ctrl+m or Ctrl+d. Any of the first three keystrokes will generate a terminating newline character that will get to the remote side. Even if you want to send Ctrl+c, Ctrl+z, Ctrl+l (to clear the screen) or e.g. sole q to exit a remote less, or ↑ to use the history of your remote shell, the only way to send it without a newline character is Ctrl+d. But…
If you hit Ctrl+d twice (or Ctrl+d just after Enter or equivalent) then you will cause the local ssh "see" EOF it never expects while reading from a raw terminal (remember the tool has configured the terminal to raw and believes it's still raw). In my tests ssh stops reading after "seeing" EOF, it becomes virtually useless and has to be killed eventually (and the local terminal has to be reset with stty sane).
You can disable the local function of Ctrl+d (and thus make Ctrl+d generate ^D that you can send to the remote side with Enter) by adding eof '' to our stty … command, but then you will lose the ability to send something without a newline character at the end.
When you send a line to a remote shell, the shell will echo it on its own. This is normal. If you want to suppress this echo, you need to reconfigure the remote tty (stty -echo).
opost enables postprocessing output. We need this because we explicitly want onlcr, without it each remote echo will appear in somewhat unexpected place. There may be other postprocessing options affecting output and in general you may want to turn them off. If you suppress remote echo (see the previous point) then you don't need onlcr and you can disable local postprocessing of output (-opost).
Expect the local line editing to interfere with output of interactive remote tools that "take over" the entire screen (e.g. htop, less, vi, tmux). Such tools need to control the terminal. As remote tools, they can control the remote tty, not the local one. They know nothing about the local tty and thus the local tty should be as transparent as possible, so like a bi-directional fifo, i.e in the raw mode. In our case it's not in the raw mode and you will see the local line editing cause overwriting and scrolling, a mess in general. This by itself will not confuse the remote tool, it will confuse you though and possibly you will send some wrong input because of this.
I'm not really sure the stty … command in this answer is the best one to enable "local line editing". Read man 1 stty, experiment, adjust to your needs.
