51–60 of 153 posts
Earlier quoted context omitted.
I would say they're mostly orthogonal. I use mosh and screen.
That sounds like a scenario for long-form work over a mobile network (eg. on a laptop through a mobile hotspot). Mosh from a laptop is a no-go for me because there's no Windows-based, full-featured terminal emulator (saved sessions, auth agents, etc) that supports mosh.
Mosh is great, but I kind of stopped using it once I discovered Tmux so I could resume a session if the connection dropped. It's not that Mosh does anything wrong , but SSH has more features, and is supported by basically everything ever. Consequently, I stick with old-school SSH.
On my laptop I have a mosh session open to my remote shell basically all the time. In situations with spotty net access, it's actually a pretty reliable "canary" that indicates whether I have any access at all.
Mosh is great, but I kind of stopped using it once I discovered Tmux so I could resume a session if the connection dropped. It's not that Mosh does anything wrong , but SSH has more features, and is supported by basically everything ever. Consequently, I stick with old-school SSH.
tmux complements mosh, it doesn't quite replace it. For me, the whole point is that you don't have to "resume a session", it just happens. On my laptop I have a mosh session open to my remote shell basically all the time. In situations with spotty net access, it's actually a pretty reliable "canary" that indicates whether I have any access at all.
I have mostly gone back to plain ssh. mosh was fantastic for keeping a connection running across network changes and when accessing a plain command line it does feel a bit snappier on slow connections. But screen or tmux give me persistence and re-establishing an ssh connection isn't very time consuming. A terminal multiplexer has a lot of advantages that mosh does not provide. mosh adds another layer of terminal emu…
Why not just use mosh to establish & maintain the connection then then use tmux/screen to manage the terminal sessions?
Mosh is great, but I kind of stopped using it once I discovered Tmux so I could resume a session if the connection dropped. It's not that Mosh does anything wrong , but SSH has more features, and is supported by basically everything ever. Consequently, I stick with old-school SSH.
tmux complements mosh, it doesn't quite replace it. For me, the whole point is that you don't have to "resume a session", it just happens. On my laptop I have a mosh session open to my remote shell basically all the time. In situations with spotty net access, it's actually a pretty reliable "canary" that indicates whether I have any access at all.
alias tmosh='() {mosh $* -- sh -c "tmux a || tmux"}'
I have mostly gone back to plain ssh. mosh was fantastic for keeping a connection running across network changes and when accessing a plain command line it does feel a bit snappier on slow connections. But screen or tmux give me persistence and re-establishing an ssh connection isn't very time consuming. A terminal multiplexer has a lot of advantages that mosh does not provide. mosh adds another layer of terminal emu…
Why not just use mosh to establish & maintain the connection then then use tmux/screen to manage the terminal sessions?
Termux[0], the best Android terminal emulator (in my humble opinion), recently had mosh added to its' package repository. I currently use it and it's very nice. It makes me long for a better handheld though (my 4" Moto G screen is difficult to type on, even with Hacker's Keyboard). I can have tmux sessions running on servers with say, an irc client running, mosh in, chat away for a bit, turn it off, the irc client co…
Have you tried JuiceSSH by any chance? Curious how the two compare.
I'm not a security researcher, but somehow I suspect the "maintaining connection while switching networks" holds potential for a flaw.
The connection is set up over SSH, and mosh-client generates a random AES-OCB key and sends it to mosh-server. Packets are sent over UDP, protected using authenticated encryption, and discarded if they fail integrity protection (which is fine, since packets could just be dropped and perhaps corrupted anyway because of bad network connections). Replayed packets are invalid. At that point the client's IP address no longer matters, since it's the only entity with the key. The server accepts valid packets from anywhere, and also sends packets to the IP address that most recently sent it a valid packet.
This should as much protection as an SSH connection over TCP. One thing I'd worry about is whether the server or client can be DoS'd with invalid packets. Is there anything else that seems concerning?