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.
I quite like the idea of this, but it would be a very hard sell to most infra and security teams IMO. Installing a 3rd party agent that in some way permits shell access to a server and (I assume) needs to run constantly is definitely going to raise a few eyebrows especially when the benefit of using is actually fairly low.
BUT! I would 100% use this as an interview tool; I run our more junior candidates through a couple of short troubleshooting scenarios that involve them SSH'ing to something and doing some basic Linux troubleshooting. This tool would make that process much much better especially now that our interviews are mostly remote.
> Installing a 3rd party agent that in some way permits shell access to a server and (I assume) needs to run constantly is definitely going to raise a few eyebrows especially when the benefit of using is actually fairly low.
Yea, I wouldn't go this route to just get the pairing functionality, but Teleport does have other utility around audit, SSO integrations, etc. So there are companies that use Teleport as the primary SSH access if there needs match what Teleport offers.
> Installing a 3rd party agent that in some way permits shell access to a server and (I assume) needs to run constantly is definitely going to raise a few eyebrows especially when the benefit of using is actually fairly low.
You're already running sshd. Teleport is a drop-in open source replacement, which offers some interesting features like certificate-only auth (removing the need for pubic/private keys), SSO integration, RBAC over SSH, support for protocols other than SSH (Kubernetes API and major OSS databases), and syscall level authorization and audit, so quite a few security teams have appreciated it lately.
Disclaimer: I work at Teleport and have been a maintainer for the first 3 years.
SSHD has a proven track record. A program (open source or not) that replaces a proven bastion of security while offering "some interesting features" is exactly the sort of thing a security team will balk at.
Software that's a "known quantity" that a lot of people can support is a big thing when it comes to security. I've not heard of Teleport until this post.
Don't get me wrong, I'm sure Teleport is wonderful at what it does, probably more secure than SSHD etc. But it hasn't earned that trust amongst a wide base yet so people will be hesitate to use it. Hell even mosh can be hard to get as a trusted thing.
Why instead start thinking about a damn really spread infra?! Or why the hell doing WFH against a central infra instead of having a spread one? Surely some servers somewhere are needed, but much of the actual work can be perfectly done locally on desktops, sharing just the outcome. That's of course demand certain things remote side, like a locked dedicated room in the worker house etc, a thing that should be required anyway to avoid famous Judge-cat or naked MP on cam and many others we all know. Surely demand a big infra change, but it's a nonsense working in a distributed manner with a non-distributed infra/tools.
I mean things from why instead of mandate VDIs crap companies who do WFH do no give managed desktops instead? Very basic examples as such that do not demand even significant revolution in operation terms, only a bit of logistic which is needed anyway.
I understand that in a liquid world no one want to pour money on something uncertain BUT on the workers side, those who are willing to WFH can simply state that and organize themselves to offer a room with basic stuff, receiving just compensation from offering room, furniture, connection etc, the company only provide needed gears managing them from remote, the same they provide to the office minus furniture, cleaning service, ... plus a smaller compensation to the worker. Again very basic examples. Things those who really want WFH would do anyway and on company side does not represent a specific capex nor opex nor a specific risk.
Hybrid working do not work anyway:
- people in the office have to work as they were from home, witch made them unhappy;
- alternating WFH and in office means double gears or moving stuff back&forth and both are not really sustainable;
- workers do not earn nothing except of stress, companies do not save a penny since they still maintain the office, less used than normal.
After have imposed to many WFH a significant slice of them now want such mode and no coercive means will make them change advise, so trying to state "all ended, now back to the office" will not work anyway, at least not without a significant price for the company and for some workers. Try to keep the feet in two different shoes does not work either, see above, so? IMVHO it's time to really discuss who can go full remote, with casual meetings few times a year as needed, and who can not or are not willing to. Workers and companies have anyway to face the challenge so why keep it up in emergency crappy mode?
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.