QUIC and KCP Reconnection Support

[kitknox]

I am the author of the terminal app Rootshell and just finished implementing initial support for connecting to tsshd-enabled-servers. As the app supports not just macOS but also iOS, iPadOS and visionOS there is an app lifecycle issue that has been challenging. On the client side the current architecture of localhost sockets is problematic as they do not survive background suspension states on iOS. In order to achieve recovery from background to foreground I had to migrate all of these to pipes within the process namespace. Otherwise the internal state of KCP and QUIC end of getting closed down and then there is no way to recover.

The larger challenge was how to achieve parity with our existing mosh compatible client which is able to fully restore from app restarts as we save all of the session credentials securely in the local device keychain and bootstrap on new app launches from that data. In order to connect to tsshd there is no reasonable way to serialize all of the state of either KCP or QUIC connections, and the existing tsshd daemon does not accept connections after the first session is established.

I am finishing up testing and will send over an initial PR which adds support for full reconnection and session resumption over both KCP and QUIC. With this change in place users of Rootshell can resume sessions after app and device restarts. Did you have plans already for how to handle this condition? Are there any security implications I might be missing that you were attempting to prevent by only allowing the initial connection?

Our initial support is available in the build that just went live if you want to check it out at beta.rootshell.com for macOS direct downloads and links to the TestFlight build for the other supported platforms.

[lonnywong]

Glad to hear that Rootshell now supports tsshd as a server.

I do plan to remove the localhost listening. My idea is to have serverProxy and clientProxy each implement the net.PacketConn interface, and then pass them directly to QUIC and KCP.

Also, while the QUIC and KCP server sides only accept a single connection, serverProxy is designed to support swapping connections as needed.

[kitknox]

I've submitted a pull request for your review which addresses the gaps I found when successfully handling the app termination scenario. It has been actively tested with Rootshell as the client with the build that is publicly available. I did not currently tackle a reference equivalent on the go client side at this time. Care must be taken to securely handle the credentials for any session resumption capabilities. Implementing this in the regular client would be a nice feature as well and the provided server changes get you closer.

It is great to hear you have plans on the localhost listening side. Would you like me to clean up and submit the pipe changes that I'm currently using on the client side? I've also created a gomobile bridge that I use to build an XCFramework that links into the rest of my project.

[lonnywong]

I see that the Rootshell documentation mentions "Auto-start tmux - Automatically attach to or create tmux sessions on connect". Does this mean that when restarting, it's not necessary to establish a connection with the old tsshd process? Instead, can you simply SSH in to create a new tsshd process and then attach to the corresponding tmux session?

[kitknox]

These are really two separate things. The auto-starting of tmux is for the subset of people that are tmux users and don't want to have to manually type "tmux new" or "tmux attach" when connecting to a given server. It's just inserting that into the PTY after connection. In general, zellij, tmux, screen, etc., are all options for folks to persist sessions on a remote server which they can connect back to later via other remote or local terminals.

These are all generally a mixed bag, as you are trading off the full native terminal experience with another layer in between. Everything gets impacted from the OSC support, copy/paste, terminal scrollback, etc. With the existing tsshd, as long as the app hasn't been restarted, it can keep things going. With the additional protocol changes, it's able to be fully terminated and then fully restore sessions without any reliance on things like tmux, etc.

They also mix together. For example, let's say you had a terminal connected over tsshd and had manually launched tmux into a specific session. You switched to another app, and the client was terminated. Upon your return, everything just automatically picks back up where you left off.

[lonnywong]

As the client, are you implementing the tsshd protocol directly yourself, or are you calling tsshd as a library? If you are calling tsshd as a library, when using the KCP protocol, after a rekey is triggered, the original key can no longer be used to establish a new connection.

[kitknox]

The initial launching of tsshd is handled directly by my app to get the bootstrap JSON. That then hands off to gomobile compiled C wrapper back into your go client for just the transport layer.

I confirmed that the rekeys are working, and that the current Rootshell app is indeed failing to reconnect over KCP after a rekey has taken place. My initial reaction is that the server could keep and reset back to key0 for reconnects, and then do an immediate rekey following the reconnect. This should retain the forward secrecy principle for the remainder of the data flow but allow the reconnect to leverage its saved state to perform the reconnect.

I think the scope may only require a change to rekey.go and could be gated on a command line argument where this fallback is only enabled in cases where clients have specifically requested it for the duration of their session.

[lonnywong]

A new startup argument can be added to tsshd. When started with this argument, the server will accept new connections and keep key0 during rekey. If started without the new argument, tsshd will continue to accept only a single connection as before. Additionally, the client should trigger rekey immediately after establishing a connection.

[kitknox]

I have completed an implementation of this and it is working well so far with Rootshell now able to reconnect after rekey events. I will update the PR after giving it some more bake time.

[kitknox]

Just following back up as I've pushed my latest tested changes and feel they are now ready for review. I added a new --reconect cmd line argument which the latest build of rootshell now sends when setting up a new session. When the argument is not present the new reconnection logic is not used and clients cannot reconnect back on key0. Luckily the existing server silently continues even when it doesn't have this support which made the client side integration there easier.

I've been running with aggressive key rotations on my client side to ensure this works well. Happy to address any questions you have.

[lonnywong]

@kitknox Thanks for your contribution! In the end, tsshd will implement the following two features:

• Add a --reconnect startup option to allow another client to attach using a new connection.

• Remove the localhost listener and instead directly implement the net.PacketConn interface.

---

Luckily the existing server silently continues even when it doesn't have this support which made the client side integration there easier.

For upgrade compatibility, this is intentional. I deliberately avoid using third-party argument parsing libraries and instead implement a simple custom parser myself.