mgkuhn
commented
2 weeks ago Reimplementing tmux or GNU Screen on Windows would seem to be a project completely independent of OpenSSH, so this project may be the wrong place to suggest this. The only link here is that both tmux and Screen rely on the pseudo-TTY (pty) facility of Unix/Linux to be able to look to applications like terminal devices, as does sshd, and the fact that the OpenSSH for Windows project has led to the implementation of a vaguely similar facility in Windows, namely ConPTY, might be of use for such a project.
Note, however, that when accessing tmux via SSH on Unix/Linux, two PTYs will be nested, one used by sshd to emulate a terminal device, and one used by tmux to emulate a terminal device. I don't know if ConPTY can be nested in a similar fashion, as it really mainly exists to do something different (namely mapping a serial-port-like VT100 terminal interface onto the ConsoleAPI). Can ConPTY be nested?
P.S.: Tmux predecessor Screen (first released in 1987) long predated SSH and was already popular among VT100 serial-port terminal and telnet users.
Summary of the new feature / enhancement
On Linux, you can use something like tmux to keep a long lived session, but the equivalent doesn't exist on Windows.
Proposed technical implementation details (optional)
I think how this could work as a new exe for a sshd subsystem that can connect to a registered PowerShell session (either create a new one or connect to existing one). The PowerShell process would have to be decoupled from the sshd created job object and we would probably also need configuration for life of the session so it's not kept up perpetually.