7 ms·
Show HN: XPipe, a brand-new type of remote file browser and shell connection hub
Hey HN, I built this over the last year as I always wanted to have an easy file and terminal access to all of my servers, including containers and clusters that you normally can't connect to with existing solutions out of the box.
At first glance it might not look very novel, but if you dig a little deeper, you will see that the entire foundation of how it communicates with remote systems is completely different from any other solution out there. What happens in the background can essentially be explained this way: It launches a local shell process like cmd, sh, etc. and in it executes a command that opens a remote shell connection such as ssh user@host. All communication is then done through the stdin/stdout/stderr of that process. From there, it detects what kind of server and environment, e.g. shell type, os, etc. you have logged into and adjusts how it talks to the remote system. By then using file system related commands such as ls, rm, touch, etc. and its equivalents, it can realize a functional file manager that works on essentially every system without any protocol requirements. For other types of connections, it can just execute things like docker exec -i to open a shell into a container and work the same way. Right now it supports:
- SSH by running your locally installed SSH CLI client
- Docker, Podman, LXD, and Kubernetes containers
- WSL, MSYS2, and Cygwin environments on Windows
- Various other things like some VMs for VMware and Proxmox, but work is still going on on there
This approach to delegate everything to your installed tools is also utilized for other tasks. That means that I can save a lot of development time while you can happily use the tools you are comfortable with in conjunction with XPipe. In fact, XPipe doesn't ship with any libraries or tools for remote shell connections, protocol handling, or terminal integration at all. It just delegates everything to your own text editor, terminal emulator, RDP clients, and more.
Due to its nature, XPipe has to handle a lot of sensitive information like passwords, keys, and more. To tackle the topics of security and privacy, I put an emphasis on security settings and created a dedicated security page in the docs that should hopefully contain all relevant information. There is also a password manager integration, so you don't have to store any sensitive information in XPipe itself if you use a compatible password manager.
As it is a common use case to synchronize connection information across many systems, e.g. your desktop at home and laptop for travel, there is also a git integration which allows you to have XPipe automatically synchronize all connection information with a remote git repository of your choice. It supports any git remote repository, advanced authentication measures like SSH auth, GPG signing, and more. You can also use this for collaboration if you're working in a team.
The early stage development has been quite challenging as this new approach requires a completely new implementation, but I am confident that it's ready now. I appreciate any kind of feedback from you to guide me in the right development direction from here.
Enjoy!
- scumola 2y agoI don't like that I can't connect to a RHEL 8 machine (that doesn't have a subscription enabled yet) without buying the Pro version of XPipe ($50). Definitely not in the open-source mindset.
- crschnick 2y agoThe idea behind that is that people usually don't run RHEL for fun, there is mostly a business need for that. Especially since there are distros like Alma Linux out there, which you can use with XPipe for free.
- vzaliva 2y agoLook like a nice, very polished product. It is a commercial product with free Community Edition. Unfortunately for me the restriction on not supporting Yubikey ssh authentication on free edition is a show stopper. I do not consider Yubikey to be "commercial" feature - I use with my private computers.
- crschnick 2y agoAlright thanks for the feedback on the yubikey. I assumed that yubikeys would be found pretty much only in enterprise environments but perhaps I was wrong there. Maybe I can find a solution to that. The free plan restrictions are not perfect yet and I was planning to experiment with different solutions to it.
- philsnow 2y agoI had a similar thought when looking at the Pricing FAQ section "Where is the differentiation between non-commercial and commercial systems?", which lists among other things Proxmox VE, which itself is open source and anybody is free to use it for free without commercial support. Lots of people use it for homelab-type things, or in academic or test environments. Would you consider detecting whether each PVE instance the user connects to is a licensed / subscription-supported instance, and allowing non-licensed XPipe to connect to non-licensed PVE instances? There is an API for it already, see the 'level' field in https://pve.proxmox.com/pve-docs/api-viewer/index.html#/cluster/status https://pve.proxmox.com/pve-docs/api-viewer/index.html#/clus... .