tmate is pretty similar but there are a few things about it architecturally that are different I think. The person connecting to you connects through a tmux server on the tunneling host rather than directly to your tmux session. This means that the tunneling server can see and modify everything sent over tmate. If the tunneling server is untrusted or compromised, an attacker would be able to run commands on your machine. Unfortunately, to make things worse, the ssh key fingerprint of the tunneling server is not bundled with tmate, so during the first connection to any tunnel an attacker performing a man-in-the-middle can spoof the server and use the fact that the server is trusted to run arbitrary commands on your machine. The attacker can either man-in-the-middle the person running tmate or the person connecting to the tmate user to perform this attack.

This more complex architecture is likely why tmate is using libssh even though libssh recently had a very serious authentication bypass vulnerability (CVE-2018-10933). These architectural choices may provide benefit in certain circumstances, but we thought were unnecessary just to share a shell.

Assist has a simpler architecture and is built on top of unmodified Screen and OpenSSH (we use the installed binaries on your machine). The tunneling servers are designed to be completely untrusted, and the command you paste to the assistant contains all the information necessary to prevent a man-in-the-middle attack from seeing or modifying the session. We hope to add more features in the future and felt that starting with a simpler architecture would help with that.

The main difference is we use a standard openSSH setup for tunneling - a full ssh key exchange is performed between you and the assistant.

We’re also a paid service so we’re incentivized to make sure things run reliably and customers are well supported.