I suspect the encryption here is broken due to CTR mode AES with IV reuse. Try printing out the IV in the segment function. It's the same value across sessions.<p>Another thing I see is that AES-CTR is being used alone, so there is no integrity guarantee for the messages.<p>I didn't have time to look into it any more deeply. The user interface and concept look really nice, but I would strongly recommend a cryptographic audit. In general, you shouldn't have to reach for the subtle constructs in a cryptographic library to build product features.
Really fun!<p>I have been experimenting with similar idea myself. I was curious on how you handle instantiating the terminal state for new clients. Seems like you're storing a buffer [0] of past output, and replaying that?<p>[0] <a href="https://github.com/ekzhang/sshx/blob/91c82d46cde4d1ffa0ae34e2a9a49911e2e53baa/crates/sshx-server/src/session.rs#L26">https://github.com/ekzhang/sshx/blob/91c82d46cde4d1ffa0ae34e...</a>
Super cool. Our students are using ttdy[0] and tmux for providing shared access to a configured environment, but your solution seems much more flexible :) I'm going to start experimenting with it for our next courses, thanks!<p>[0] <a href="https://github.com/tsl0922/ttyd">https://github.com/tsl0922/ttyd</a>
I’ve been using GoTTY (<a href="https://github.com/yudai/gotty">https://github.com/yudai/gotty</a>) to do the same thing, combined with ngrok or Cloudflare tunnels to get a publically accessible URL. To enable multiplayer mode, just need screen/tmux.
Web developers live in the web, but we still need to interface with VMs over SSH. Bridging that gap in favor of the developer is genius. The multiplayer aspect, the shell one-liner to bootstrap the whole process, everything about this is great.
Why does the sshx.io/get URL detect a browser using the Accept-Encoding header and return 404?<p>Generally I don’t have much to say about curl | bash, but going out of your way to hide the script is a bit suspicious.