Feedback Request: New WebSSH2 Client and Server Architecture

[billchurch]

Overview

I've been working on significantly refactoring WebSSH2, aiming to improve modularity, flexibility, and compatibility with different frameworks. I want to share this work in progress and gather feedback from the community.

Key Changes

1. Split Architecture: The project has been split into separate client and server components:

   • Client: webssh2_client
   • Server: webssh2 (bigip-server branch)

2. Targeted Node Version: The server has been refactored to target an older version of Node.js (v6.9.1) for a specific use case. However, after I get some feedback here, I intend to release a newer version of the server code targeting node v18 (or greater, depending on the feedback).

3. Docker Image: A new Docker image is available for testing:

   docker run -it --rm --name webssh2 -p 2222:2222 -e DEBUG="webssh2*" billchurch/webssh2:bigip-server

4. Modularity: The new architecture allows for easier client customization for different frameworks while maintaining a consistent server backend.

Goals

• Enhance flexibility for integrating WebSSH2 into various environments
• Improve maintainability by separating client and server concerns
• Enable framework-specific client implementations

Feedback Requested

1. Does this new architecture make sense for your use cases?
2. Have you encountered any issues with the current WebSSH2 that this might address?
3. What features or improvements would you like to see in this new version?
4. Do you have any thoughts on the documentation structure and content in the new repos?
5. What did I miss that you used from the previous client? What features do we need to add?

Next Steps

Based on community feedback, we'll refine this approach and merge it into the main WebSSH2 project. Your input is crucial in shaping the future of WebSSH2.

Please review the READMEs in both repositories for more details:

• webssh2_client README
• webssh2 (bigip-server) README

Thank you for your time and input! -Bill

[billchurch]

webssh2_client improvements:

• New Login Dialog for /ssh/ route

• Modal for re-authentication

  

• Terminal Settings

  

• Autolog Feature to log sessions on connect

• Logs save to browser localStorage

• Significant debug system for browser (enabled by localStorage.debug='webssh2*' from browser console:

  

[billchurch]

bigip-server what does it all mean

Please ignore the name; you don't need a BIG-IP to run this. The docker has everything you need. Eventually, this will replace an existing solution that runs on a BIG-IP as an iRule.

[israel-tsadok-silk]

First, I would like to say thank you for this project. We've been using it for almost 2 years now for quick access to our testing environments, and it has been very popular among our internal users.

Our use case is fairly simple: we have an internal website that allows users to bring up a test VM. Once the VM is up, the user can click it, and a webssh2 terminal gets opened in a new tab, already authenticated, ready for commands. While this may seem a little crazy from a security perspective, these are ephemeral test systems, only accessible locally, and the number of people with access to the network is small.

I did some quick testing of webssh2:bigip-server. These are my observations:

• In the docker image, the config file moved from /usr/src to /usr/src/app, and also now the default config "just works", so it just silently failed to take my config file, which made it tricky to figure out what happened. The new location makes more sense, but maybe this needs to be highlighted somewhere, or a warning should be displayed if a config.json file is found under /usr/src.
• It looks like the new server does not support /ssh/host without a hostname, which is central to our use case. If I access /ssh/host/:host_ip, it still asks me for credentials, ignoring the "user" setting in config.json.

The split makes sense, the code looks cleaner, and I appreciate the extra documenation.

• You should have a clear banner at the top of the webssh2_client README, directing the casual users to the webssh2 project. The way it currently looks might confuse some people, because the README kind of makes it look like a solution rather than a component.
• It's not clear what is the point of the "Routes" section in the webssh2_client README, since it explicitly says that these routes are implemented in the server.
• I am not a node.js developer, so I don't know how trivial this is, but maybe have some instructions for how to set up a server+client development environment that allows working on both components together without having to build a client package every time.
• The server README on the bigip-server doesn't mention webssh2_client, and still has an outdated tip about customizing the javascript.

I have a couple of items on my wishlist, though I'm not sure if this is the right place for them or if I should just create separate issues, but you asked, so here goes:

• Optional confirmation before closing the tab. A very common keyboard shortcut for Linux is Ctrl-W, and people keep accidentally closing their ssh tabs when trying to delete a word. Browsers allow setting a beforeunload event listener that asks for a confirmation before the tab gets closed, which would be very helpful. When I tested this, I was able to add a confirmation but the session got disconnected anyway, so this might require some tweaking of the current event handlers.
• Allow setting environment variables from the URL. I would like to be able to create a link that would open a session and (for example) immediately open vim on some file. I think the best way to implement this is to allow a URL like /ssh/host?env=VIM_FILE:somefile.config and then use that env var in .bashrc to decide what to do.

I don't think either of these are easier to implement with the new architecture.

[billchurch]

Thanks; this is precisely what I was looking for. Based on your feedback here and in webssh_client, I opened issues to track these requests/fixes and changes.

I mostly appreciate the notes for documentation, as it can be a struggle to document some of these changes or omissions.