Hello there,
I’m proud to share a major development status update of XPipe, a connection hub and remote file manager that allows you to access your entire server infrastructure from your local machine. It works on top of your installed command-line programs and does not require any setup on your remote systems. So if you normally use CLI tools like ssh, docker, kubectl, etc. to connect to your servers, you can just use XPipe on top of that.
Here is how it looks like if you haven’t seen it before:
Coherent desktops
XPipe now comes with support for remote desktop connections. VNC connections are fully handled over SSH and can therefore be established on top of any existing SSH connection you have in XPipe. RDP support is realized similar to the terminal support, i.e., by launching your preferred RDP client with the connection information. X11-forwarding for SSH is also now supported.
With support for remote graphical desktop connection methods as well now in XPipe 9, the big picture idea is to implement the concept of coherent desktops. Essentially, you can launch predefined desktop applications, terminals, and scripts on any remote desktop connection, regardless of the underlying connection implementation. In combination with the improved SSH tunnel and background session support, you can launch graphical remote applications with one click in the same unified way for VNC over SSH connections, RDP connections, and X11-forwarded SSH connections.
SSH X11 Forwarding on Windows via WSL
You can now enable X11 forwarding for an SSH connection.
XPipe allows you to use the WSL2 X11 capabilities on Windows for your SSH connection. The only thing you need for this is a WSL2 distribution installed on your local system. XPipe will automatically choose a compatible installed distribution if possible, but you can also use another one in the settings menu.
This means that you don’t need to install a separate X11 server on Windows. However, if you are using one anyway, XPipe will detect that and use the currently running X11 server.
SSH connection improvements
-
All tunneled and X11-forwarded custom SSH connections are now properly detected and can be toggled on and off to run in the background
-
The connection establishment has been reworked to reduce the amount of double prompts, e.g. for smartcards or 2FA, where user input is required twice
-
The custom SSH connections now properly apply all configuration options of your user configuration file. They also now correctly apply multiple options for the same key correctly
-
Any value specified for the
RemoteCommandconfig option will now be properly applied when launching a terminal. This allows you to still use your preexisting init command setup, e.g. with tmux -
There is now support defining multiple host entries in place in a custom SSH connection. This is useful for cases where you want to use ProxyJump hosts in place without having to define them elsewhere
Terminal improvements
The terminal integrations have been reworked across the board. The kitty terminal is also now fully supported with tabs on both Linux and macOS. The Warp terminal integration now correctly enables all Warp features on remote shells. On macOS, other third-party prompts also now work properly in the launched terminals.
Password manager improvements
The password manager handling has been improved, and some potential sources of errors and confusion have been eliminated. There are also now a few command templates available for established password managers to quickly get started.
A note on the open-source model
Since it has come up a few times, in addition to the note in the git repository, I would like to clarify that XPipe is not fully FOSS software. The core that you can find on GitHub is Apache 2.0 licensed, but the distribution you download ships with closed-source extensions. There’s also a licensing system in place as I am trying to make a living out of this. I understand that this is a deal-breaker for some, so I wanted to give a heads-up.
The system is designed to allow for unlimited usage in non-commercial environments and only requires a license for more enterprise-level environments. This system is never going to be perfect as there is not a very clear separation in what kind of systems are used in, for example, homelabs and enterprises. But I try my best to give users as many free features as possible for their personal environments.
Outlook
So if you gave this project a try a while ago or it sounds interesting to you, you can check it out on GitHub! There are still more features to come in the near future. I also appreciate any kind of feedback to guide me in the right development direction. There is also a Discord for any sort of talking.
Enjoy!
What are the chances of an official flatpak getting maintained so us lazy folk don’t need to keep up with the GitHub repo/site for when updates drop?
Edit: Also do you have any plans to add NX support?
Sadly this is not possible due to the flatpatk sandbox, at least without having to rewrite basically the entire application. You can’t open other applications or shells from the sandbox, so nothing would work. Someone told me that it is possible in theory to reduce the level isolation of the sandbox via flatseal, but that would require the user to perform additional operations to make it even work. If it is not going to work out of the box, a flatpak version would not make a lot of sense.
There is an optional automatic update check included that will notify you when a new version is available. You can also automatically install the new version through that, but that is up to you.
For NX, I assume you’re talking about this: https://www.nomachine.com/. I would have to look into that, it depends on how open the protocol and platform is. Without looking too much into it, I would assume it has some basic open component but since there is a company involved, there’s probably some proprietary vendor lock in. It’s probably the same as with VNC where there is an open protocol spec, but RealVNC also develops their own closed spec to lock out any third party clients from interacting with their tools.
Yeah NX is probably not going to be an easy one to implement.
https://en.m.wikipedia.org/wiki/NX_technology Scrolling down to NX Derivatives And Forks will quickly get you a picture about the state and licenses.
How do I install this on fedora? I’m not to keen on curling a bash script and running it. Thanks!
Edit: for fedora atomic, the answer is to download the rpm and overlay it with rpm-ostree install
Yeah I guess I haven’t really accounted for these atomic versions, so I don’t think the install script would have worked.
I might have to try out fedora atomic myself one day.
If you submit the rpm to rpm-ostree then users can just find it from there with rpm-ostree install xpipe.
That requires an overlay but the alternative is a flatpak which won’t work for an app like this I think anyways.
Users that install brew can just get it from here as a proper containerized install rather than an overlay.
The script is definitely not great as he primary way to install, everyone doing that should be doing so very reluctantly. Getting the rpm into package managers will go a long way.
That being said, xpipe is amazing. Only used it for a few hours and already love it and can’t believe I didn’t have it sooner.
The script was created initially because a surprising amount of users were a little bit overwhelmed with manually installing a .deb or .rpm file. I guess with package manages nowadays, you don’t handle raw files that often anymore.
I will see what I can do about submitting it to package managers.
Very interesting, there is some proprietary “Terminal + Filesystem” app on windows that had this, what was it?
Also, is X11 as secure as VNC or RDP? I mean it is likely used as much.
And where to position moonlight and sunshine here?
Perhaps you are thinking of MobaXTerm?
X11 forwarding is as secure as your SSH connection as everything is handled over that as long as you trust the system you connect to as it can send some X11 commands to the client. VNC by itself is insecure but XPipe tunnels all VNC connections via SSH as well, so it is secured as well. With RDP, I would argue that there are less sophisticated authentication options available for RDP than for SSH.
I think moonlight and sunshine are intended for gaming while this more intended for server administration tasks.
Yes, MobaXTerm
Thanks for the heads up! So both connection protocols use ssh, which is supposedly damn secure.
Moonlight is supposed to way better for latency, so if it can be secured as well, may be a better VNC?
I think most of the users have something like VNC set up, I’m not sure how widespread moonlight is in the server space. Anyone who comes across this question, feel free to tell me whether moonlight can be considered for server administration.
Oh cool I’ve been looking for something like mobaxterm but for Linux. I’ll definitely check this out.
