Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback Request: New WebSSH2 Client and Server Architecture #368

Open
billchurch opened this issue Aug 19, 2024 · 7 comments
Open

Feedback Request: New WebSSH2 Client and Server Architecture #368

billchurch opened this issue Aug 19, 2024 · 7 comments

Comments

@billchurch
Copy link
Owner

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:

  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:

Thank you for your time and input!
-Bill

@billchurch
Copy link
Owner Author

webssh2_client improvements:

  • New Login Dialog for /ssh/ route
  • Modal for re-authentication
image
  • Terminal Settings
image
  • 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:
image

@billchurch
Copy link
Owner Author

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
Copy link

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
Copy link
Owner Author

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.

@haso2007
Copy link

Dear billchurch
It look the server version is good and faster then the client one. I like the font setting. BTW, I have a old private problem, because I use it in the limit edge browser,IT might have turned off HTTP basic authentication, so instead of showing a prompt for the username and password, the Edge browser just shows an error message. Is it possible for you to create a login page directly, rather than using a popup from the browser?

@billchurch
Copy link
Owner Author

@haso2007,
Can you tell me what version of Edge you’re using and on what OS? I’ll look into the issue.

@haso2007
Copy link

Here is the information:
Microsoft Windows 10 Enterprise Edition
OS Version: 10.0.19045, Build 19045 (N/A)
Microsoft Edge for Business
Learn more about Microsoft Edge for Business
Version 129.0.2792.52 (Official build) (64-bit)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants