Kill mosh server11/13/2023 ![]() user goes "Huh.that didn't work", repeats on his other phone.user tries to attach with new mosh client, pastes state, startup fails for whatever reason (probably network connectivity), but in a way that has traffic observable by an adversary.user detaches original mosh client, gets session state, copies it.Now that has explained his worries, I'm scared too, because I can easily construct a foot-shooting scenario that doesn't even need any help from your friendly local nation-state surveillance agency: #505), and such problems would be compounded if mosh-client was allowed to resume on a different terminal. We could solve this by adding a way to negotiate a new session key for each resume, but that means protocol changes and extra security-critical complexity.Īlso, from a terminal perspective, the existing C-^ C-z support is incomplete (e.g. The mosh-client internal state includes a cryptographic nonce that must never be reused, and I worry that if you allow the state to be serialized, it would be hard to stop users from unknowingly compromising their own security. This feature request scares me from a cryptographic perspective. Additionally, there are non-security issues complicating the implementation of migrating the terminal state to a new terminal. In any event, although on-disk encryption is more or less a solved problem, the security concerns here are more subtle than an attacker directly reading the state while it’s sitting around on your disk. I know this bug isn't open anymore and this isn't exactly the same subject, but I dislike that the solution to a situation resulting in losing control of my jobs is "hey dummy why didn't you use a muxer?" when I'm using the tool the same way I used the one this is effectively replacing, but the tool doesn't break in the same Mosh uses no public-key cryptography (except in that the mosh wrapper script invokes ssh to establish the initial connection and start mosh-server). Convenience wins, and I'll never kick myself for losing control of a really important job. moshrc when I connect to the remote which could set some things and pull me into a tmux session by default means that I no longer need to remember to sync local configs which is ultimately another form of special behavior as a user who has to evaluate their local system before ever using mosh. Regarding 2 I may not care whether my job is unrecoverable on some system, but I do on another. Even so, they have had various security holes over the years in this I already just use mosh - machine tmux attach, and having local aliases does not address my comment(s) because 1) The user still has to change their behavior by explicitly choosing to change the command you're using (and so aliases offer no benefit over explicit commands) 2) This is something that is convenient only if you can specify it remote-side. ![]() Screen and tmux don't have these problems because they aren't trying to cryptographically secure access to the session they just rely on normal Unix permissions (enforced by the kernel) to make sure users only attach to their own sessions. It's easier just to not allow this at all. We try (and so does SSH) to make it as hard as possible to get that secret key.Īlthough we could in theory create a backdoor so that a newly-formed client could somehow extract the key and latest nonce from an already-running server, this creates a lot of security implications in the common case - e.g., how do we ensure the nonce won't get reused how do we ensure that the first client is really dead how do we make sure a bad guy can't steal the key using this mechanism. The reason is that the client and server are bound together by their shared knowledge of the secret session key. ![]() ![]() If an SSH client dies, there is no way to reattach to the corresponding sshd from a new client. Many Mosh users use it together with screen and like it that way. ![]() Mosh is a substitute (in some cases) for SSH, not for screen. Well, first off, if you want the ability to attach to a session from multiple clients (or after the client dies), you should use screen or tmux. ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |