I know this is hard for security and dozens of reasons, but the thing that drives me nuts about mosh is not having SSH's ControlMaster protocol so I can multiplex. It's a protocol thing, so not directly fixable via a compatible implementation. But it just sucks, I have so many tabs, and I have each one having to do the deed again, maintain it's own connection.
You can get most of what you want today without a protocol change. mosh only uses ssh for the initial hop, and it just runs whatever ssh is on your PATH, so your ~/.ssh/config applies. Put a ControlMaster/ControlPersist entry in there and only the first tab actually authenticates. Every tab after that reuses the socket, and the "ssh host mosh-server new" step is quick. Each tab still ends up with its own UDP connection, but that's one tiny server process and one key per tab, not a new login.
Sharing one SSP connection across several terminals is a big protocol change, and I'm deliberately keeping mosh-rs wire-compatible with upstream, so I don't want to go off on my own there. For "lots of tabs, one connection" the thing that works well is one mosh session into tmux, and tmux control mode (tmux -CC) if your terminal supports it. That gives you native tabs over a single mosh link, which is about as close to ControlMaster as you can get with mosh's design.
The chat I mentioned above linked this issue, which, to be honest, I skimmed and said, ok, yeah, Astra's right, ControlMaster seems maybe like a big no go, then never tried.
https://github.com/mobile-shell/mosh/issues/24
I tend to have ~20+ tabs open and each one has it's own tmux session inside of it, with multiple windows. I do think that making a terminal that can script and control multiple tmux sessions via control mode is, sort of, the longer destination ahead for me! That'll be exciting.
mosh-rs is a Rust port of mosh, the mobile shell. It speaks the same wire protocol, so the client works against the mosh-server already installed on your hosts, and the server works with the stock mosh client.
In Mosh, there is no native Windows client (you run it inside WSL), and there is no scrollback, which is the most-upvoted open issue on the project since 2012. mosh-rs has both.
I would especially like to hear from people who use mosh over bad links or on Windows. Any feedback/testing is appreciated
I know you were focusing on backwards compatibility, but given your understanding of terminals and scrollback, I'm curious how far vibe coding could push to retain and persist state to keep that state through restarts or reboots. Such a pain to get back to before a reboot or after accidental closing. Having effectively"undo close tab" and better persistent resume would be interesting.
herdr has good, not perfect, support to restart a session after a server reboot. It can automatically restart an agent cli while resuming the session they were running before the reboot.
I know this is hard for security and dozens of reasons, but the thing that drives me nuts about mosh is not having SSH's ControlMaster protocol so I can multiplex. It's a protocol thing, so not directly fixable via a compatible implementation. But it just sucks, I have so many tabs, and I have each one having to do the deed again, maintain it's own connection.
I chatted with Astra about this ask here: https://chatgpt.com/share/6ac42567-c404-83e8-b8fe-d29040f451...
I flip on and off using my own term-preserver toolkit, which let's me autoreconnect to servers (via ssh) and or tmux sessions automatically. https://tangled.org/jauntywunderkind.bsky.social/term-preser... . There's a variety of others like this, zmx, zmosh, https://github.com/neurosnap/zmx https://github.com/mmonad/zmosh
You can get most of what you want today without a protocol change. mosh only uses ssh for the initial hop, and it just runs whatever ssh is on your PATH, so your ~/.ssh/config applies. Put a ControlMaster/ControlPersist entry in there and only the first tab actually authenticates. Every tab after that reuses the socket, and the "ssh host mosh-server new" step is quick. Each tab still ends up with its own UDP connection, but that's one tiny server process and one key per tab, not a new login.
Sharing one SSP connection across several terminals is a big protocol change, and I'm deliberately keeping mosh-rs wire-compatible with upstream, so I don't want to go off on my own there. For "lots of tabs, one connection" the thing that works well is one mosh session into tmux, and tmux control mode (tmux -CC) if your terminal supports it. That gives you native tabs over a single mosh link, which is about as close to ControlMaster as you can get with mosh's design.
The chat I mentioned above linked this issue, which, to be honest, I skimmed and said, ok, yeah, Astra's right, ControlMaster seems maybe like a big no go, then never tried. https://github.com/mobile-shell/mosh/issues/24
I tend to have ~20+ tabs open and each one has it's own tmux session inside of it, with multiple windows. I do think that making a terminal that can script and control multiple tmux sessions via control mode is, sort of, the longer destination ahead for me! That'll be exciting.
mosh-rs is a Rust port of mosh, the mobile shell. It speaks the same wire protocol, so the client works against the mosh-server already installed on your hosts, and the server works with the stock mosh client.
In Mosh, there is no native Windows client (you run it inside WSL), and there is no scrollback, which is the most-upvoted open issue on the project since 2012. mosh-rs has both.
I would especially like to hear from people who use mosh over bad links or on Windows. Any feedback/testing is appreciated
https://github.com/Arunjay4213/mosh-rs
I know you were focusing on backwards compatibility, but given your understanding of terminals and scrollback, I'm curious how far vibe coding could push to retain and persist state to keep that state through restarts or reboots. Such a pain to get back to before a reboot or after accidental closing. Having effectively"undo close tab" and better persistent resume would be interesting.
herdr has good, not perfect, support to restart a session after a server reboot. It can automatically restart an agent cli while resuming the session they were running before the reboot.