Granted, this solution let's you give ssh access to anywhere, but usually if I want to share a terminal, it's on a server the other person has access to.
I often use tmate [1] to do this, as it simplifies some of the fiddly bits and allows granting another user temporary access without granting them credentials (eg ssh key or username/password).
I'd be keen to hear why tmate isn't a good idea in terms of security.
As I understand it, the use of tmate is not so different from physically sitting next to a colleague and both of you taking the hot-seat with the computer.
Is the vulnerability around sending a shell to tmate.io? If so, I believe there is also an option to host the software on your own server.
You don’t see the difference between: 1) allowing anyone on the Internet to use an ssh shell on an internal server that’s protected by authentication and firewalls, vs 2) someone you know, who has already been granted physical access to your location, and likely already has a security clearance as well as undergone interviews, training, and other security checks?
Most corporate networks won't allow you to open ports on your machine without approval.
Solutions like tmate (awesome btw!) don't work because they're filtered.
I use tmux with a reverse ssh to a VM in our cloud and then a colleague can forward ssh to the VM.
"tmate is useful as it goes through NATs and tolerate host IP changes. Accessing a terminal session is transparent to clients as they go through the tmate.io servers, acting as a proxy. No authentication setup is required, like setting up ssh keys."
Corporate can't block outgoing traffic on well-known ports without user impairment, even with MITM certificates in place HSTS solves that security hole making outbound 443 quite open in most networks.
EDIT:
tmate uses SSH as outbound transport, just like you are.
[1] https://tmate.io/