Idea #20802
closedEvaluate replacements for shellinabox
Description
- It is unmaintained: last commit was seven years ago. That's not a dealbreaker for a stable library but is a very bad smell for a service that's Internet-facing and has a big security surface.
- It is not packaged at all in RHEL 8+.
Research alternatives for discussion at a future engineering meeting.
Updated by Brett Smith 11 months ago
- Target version deleted (
Future) - Description updated (diff)
- Subject changed from shellinabox not packaged for RH8-based distro to Stop deploying shellinabox
Updated by Brett Smith 11 months ago
- Status changed from New to In Progress
Conveniently Wikipedia has a list. I consider these two basically tied right now:
- webssh Python project: Seems close to a drop-in replacement. The PyPI page includes examples for how to start a session from JavaScript, etc. Written in Python, last release 2 years ago.
- ssheasy: Not on Wikipedia but the top search result for "browser ssh client." Also seems very similar. Compared to webssh, it's written in Go and more recently maintained, so both of these are positive signs. The downside is it's barely documented and I'd have to dig into the source some more to figure out how much transition effort it would take.
Others I looked at and don't think we want to use:
- Bastillion: The dealbreaker is it uses a weird license, the Prosperity Public License. It's also written in Java, which I don't consider a bad thing in and of itself but as a practical matter we have less collective experience deploying Java software on the team.
- Secure Shell App for Chrome, FireSSH for Firefox: I assume we prefer to avoid any browser-specific solution.
Updated by Brett Smith 11 months ago
Brett Smith wrote in #note-8:
- ssheasy: Not on Wikipedia but the top search result for "browser ssh client." Also seems very similar. Compared to webssh, it's written in Go and more recently maintained, so both of these are positive signs. The downside is it's barely documented and I'd have to dig into the source some more to figure out how much transition effort it would take.
I am still not totally sure about this but at this point I feel confident saying it works very differently and would be less of a drop-in replacement. It looks like WASM client code in the browser opens a websocket connection to the server which in turn tunnels the SSH traffic directly. The documentation claims that the server does not see the unencrypted traffic, it only proxies the encrypted SSH traffic. I haven't audited the source but if that's true it makes sense that the way you initiate a connection is different.
While this would be more transition effort, it has some deployment benefits. It means that a cluster with multiple shell nodes could deploy a single ssheasy server (e.g., on the same node as Workbench) and have it provide service for all shell nodes without compromising security at all. From my ops perspective, that pushes it into being the front-runner as long as we're willing to commit to any necessary Workbench adaptation.
Updated by Brett Smith 10 months ago
Per engineering meeting discussion, current top candidate is to drop webshell altogether, in favor of using a container shell to a container that has all the shell tools preinstalled. Requires some business buy-in but if we get that, then the evaluation job is probably done.
We might use the ssheasy client code to help us implement container shell but that's only coincidentally related.
Updated by Brett Smith 9 months ago
- Status changed from In Progress to Resolved