Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: XPipe, a brand-new type of remote file browser and shell connection hub (xpipe.io)
136 points by crschnick 8 months ago | hide | past | favorite | 66 comments
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!




I was skeptical of X-Pipe at first, but after setting it up to access a remote docker container running Postgres that wasn't listening on a publicly accessible port, I can say that no other tool gets out of my way as fast as XPipe so I easily manage my machines and databases.


Could I use this to synchronize a docker-compose project? I’m imagining a seamless workflow for local development and prod. for certain projects it would be perfect like a blog. I’d love to not have to think about deployment at all. Like hosting a site via notion but using markdown and Astro or 11ty or similar


I guess that depends on what you mean by synchronizing here. Right now it can access and manage the raw docker containers on remote systems. There isn't special support for docker compose, but that is one possible thing I can add in the future.


Support for docker compose would be fantastic. I could envision this on a digital ocean droplet with docker compose and traefik would become my go-to method for hosting. It's already an amazing tool, though!


Mind describing the case in bit more of details? I find that I can learn on interesting approaches, especially in cases where I cannot see direct benefits/use case - i.e. here I'm not sure why and even how I'd want docker-compose to be synced - I feel there is a hidden gem in your idea!

Thank you in advance!


Interesting.

What you're describing is like how the Visual Studio Code Remote system works, but broader and untethered from an editor environment. I will have to experiment with it.


I'm not deeply familiar with the vscode internals but figured that they were doing something similar as many issues and error messages that were thrown by shells and various programs led me to some vscode issue with the same problem many times.

Because it turns out in practice some shells and programs do not like being run in the background in a dumb terminal as this is an obscure use case.


Some feedback and questions:

1. Firstly, nice work! What a cool idea and a nice looking implementation. I especially appreciate the light touch of using existing implementations for as many things as possible.

2. Thank you for providing RPMs! This is greatly appreciated.

3. Do you (or are you open to) making professional features source-available for paying customers? (so in other words would you share the source code for the closed portions, obviously with limitations redistributability).

4. I see it's Java, but what UI framework are you using? How has your experience been in it? I used a ton of Swing in the 00s and early 10s but moved to Qt for all my GUIs. I love Qt, but I do have a burning curiosity about the state of desktop GUI dev in Java.

5. I've gotten very conservative about buying software, not because of the money but because of the way "license enforcement" and other DRMs cause pain. Does XPipe implement license checks or stuff like that, and if so can XPipe function without internet for long periods of time?

6. It is very clear from reading your HN post and the website and README.md file that you are passionate, that you care a lot about your product, and also that you are thorough and thoughtful. To me this is a huge selling point because it gives me high confidence that you aren't just shipping fast and breaking things, and embracing the modern "ship it to prod and we'll find the bugs and hotfix them" approach which I loathe. Nice touches like the CLI (which offers very helpful message), and the option to "Quit" or "Minimize to tray" feel very polished and user friendly. I love being asked that instead of just minimizing to tray by default!


Thanks for your feedback. To answer your questions:

3. Making the source available would technically be possible, but I would have to consult with a lawyer for that first on how such a thing would be implemented. But I can definitely see this being a feature for the enterprise plan if the customer is interested in it.

4. XPipe uses JavaFX as the GUI framework. It might not be the most fancy and modern solution out there but gets the job done. It is still maintained, but that concerns mainly bug and security fixes. In terms of new features there isn't that much happening but that's not that bad as the desktop hasn't changed a lot over the last decade. There might be more modern solutions out there like Jetbrains Compose, but the advantage of JavaFX is that it is very stable and mature. There's also a good ecosystem of libraries for it.

5. In terms of license enforcement, it's pretty lenient. You only have to validate the license after at most 7 days, so if you are offline for a period of time it will work fine. If you are working on a fully offline system, there is also the possibility to request an offline license that will not require any internet connectivity. See https://xpipe.io/pricing#faq for that.

6. I try to do my best shipping a stable product. I think most developers would probably want to do that, but in practice it's usually investors or management pushing down from above to get features out quicker. I guess I'm in the fortunate position right now being able to choose my own development pace.


Nice thank you, I've been considering playing around with JavaFX for quite some time. Do you have any advice for someone getting started who has quite a bit of Swing experience but no JavaFX?


I think it's good to be aware that there is a lot of bad tutorials/libraries for JavaFX out there. Also many StackOverflow answers are quite outdated as the popularity hit a peak like a decade ago. Also don't use FXML (the weird declarative way of creating GUIs).

I think the best way to get started would be to download the sampler application from https://github.com/mkpaz/atlantafx. That is state of the art, good implementation. You can play around with it and jump to the source code to see how it is implemented. It contains almost everything an application needs.

Also depending how old your general Java knowledge is, the modern way of creating applications is through the module system and the jlink/jpackage tools. There are many outdated solutions for application packaging out there as well. If anything you see is using the classpath, builds jars or fat jars, or is using external tools outside the JDK, it's probably old and no longer appropriate.


Fun idea!

Honest feedback:

- Downloaded it on Mac and ran it

- Immediately on guard due to the non-native GUI

- Try to make a connection and get the following:

java.io.IOException: Unable to launch terminal Kitty: Process returned exit code 1: Unable to find application named 'kitty.app'

I don't know what Kitty is. I probably don't want Kitty. I'll probably go do something else now.

Hopefully others are able to hit the ground running and enjoy it more quickly.


I pushed an update that fixes this issue on macOS.

It seems like someone at apple thought that having mdfind always return 0 even if I didn't find anything was a good idea.


Oh that seems like a bug on my end, on macOS it seems to default to kitty as your terminal application even if it is not installed.

You should be able to fix this by going to Settings -> Terminal -> Set the terminal emulator you want to use


Reminds me of tramp-mode, but without being stuck in emacs. Nice!


As someone unfamiliar with that emacs term (more of a vim user), you had me confused for a moment there.

But after reading up on that, it is actually quite similar to what xpipe does. Good to know about, I will dig deeper into it and see what the emacs community came up with.


Often mentioned as one of _the_ function some people still use emacs. It's a fantastic way to operate on remote machines, however, it also require pretty high emacs comfortablity as well.


Reminds me of tramp, but without the freedom and power of Emacs ;)


If you want to keep using emacs, there is the possibility to launch any custom editor in xpipe via a command. You could use emacs as your primary editor with it.


Looks pretty cool. I installed on Windows, and while it automatically found all the entries in my ssh config file, it wasn't able to import the key information for these even though it's all in my file (my config works perfectly with VScode remote for example). The thought of having to manually specify each of many dozens of key files is enough to make me not want to use it unfortunately. Seems like that should be easy enough to fix though.


Thanks for trying it out and describing your issue. I assume that you mean that you have the IdentityFile option configured for every connection in your config file?

That should work though, it might not list the file as an explicit detected key-based authentication method when you edit the connection (Might be listed as None), but it should still apply the identity file option you have set in the config.

If that is not happening, then this is a bug and I can investigate that.


Yes each entry in the ssh config file has its own IdentityFile entry with the full path to the key file. Maybe it’s because they are indented an additional level more than the HostName and User fields it’s not recognizing them?


So I released an update that should hopefully fix / tweak this behavior.

I think to apply you would need to remove the config entry in xpipe and search for it again.


I updated but see no way to make it re-import the config file. Sorry to say, but I'm finding the whole thing very confusing and counter-intuitive. It should automatically import the .ssh config file when you start it up.


Alright that is good feedback. I haven't actually thought about this, but it would also make sense when a user updates their config hosts in general. There is a refresh button for the config, but that one also does not reload everything. I will definitely improve that.

About the reimport, you can right-click the SSH config root, remove it, click on the magnifying glass button on the local machine to automatically add it again with the latest info. But I can fully understand that you don't want to do that, dealing with unintuitive interfaces isn't fun.


Thanks, will try it and let you know!


The indentation shouldn't really matter, I will try to figure out what went wrong there.


If it's not a secret, what kind of activity requires having "many dozen" of key files - I currently have 3 of ssh keys and already thinking I'm doing things wrong, especially if more than 1 of them used for Github/Gitlab auths on different accounts - makes things quite messy for me.


I 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.


The 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.


I think this could help me keep track of my increasingly complex infrastructure. But this program is going to have access to... a lot of very sensitive stuff. All the private keys to login... I'd feel much more comfortable if it were open source somehow.


Well it is open-core on GitHub right now. I think full open source is going to be difficult if you're trying to sell it. At least in the desktop application space with no account setup or other service dependency it's complicated as anyone could circumvent paying by cloning it and commenting out a few lines.

But I can fully understand your concerns, establishing trust is important. At the end of the day it's up to you whether you feel comfortable enough with it.


This seems like a very reasonable response and honestly I’m kind of annoyed at everyone asking for everything to be open source all the time.


What does it do that I couldn't directly do using SSH port forwarding, jump hosts, etc?


If you are looking for key points from the perspective of a heavy ssh CLI user, you can think of it as a fancy wrapper around your existing SSH client and configuration.It will automatically detect your SSH config and supports exactly the same set of features and options as your SSH client as it internally uses that one. It doesn't try to replace your existing SSH client and configuration, it works with it.

What it will add:

- You have direct access to all systems running on the servers you connect to, e.g. docker containers, using the exact same graphical interface. On the CLI you also have that in theory, but that's tedious

- You can bring your shell environments / init scripts / aliases with you in a noninvasive way. I.e. you don't have to modify the remote system dotfiles, when you connect through xpipe it will set up any scripts you want to have available automatically

- You can link up your password manager with your SSH client and other connection methods that require passwords

- You have the ability to synchronize your connections and environments through git, including your SSH configs

- You get special integration for SSH tunnels that allows you to toggle them to start / stop in the background, you can also make tunnels automatically start on XPipe's launch

- You get an overview over all your remote connections and can access the file system of any connected remote system via a uniform graphical user interface


Thank you for the thorough reply! That convinced me to try it out :)

I've always been able to do some crazy stuff with SSH (it's really wizardry what one can do) but it definitely required using it quite frequently to remember all the commands/options etc.


This looks super impressive. I can’t wait to try it out.


Finally... I looked out for such an product for years... I definitely try it, tomorrow.


Do you have any plans to add port forwarding? This is complex, especially given what you describe with your execution model, but would really complete the trifecta of remote access (files, commands, and ports).


It supports creating and enabling SSH tunnels to forwards ports, i.e. local, remote, and dynamic port forwarding.


Sounds a bit like KDE's KIO slaves, at least in principle.


I had forgotten completely about KDE + KIO Slaves. I've been on the lookout for a filesytem browser (eg: fuse/ssh-fs-ish, ratarmount, even this monstrosity: https://github.com/zevweiss/booze ), but had forgotten about the KDE file manager having support for "weird" protocol browsing!



Interesting, have not heard of that before. But yes, it is definitely similar in some aspects to that.


Are those still being used? I haven't used Konqueror in awhile.


I was skeptical but this is pretty slick -- its ability to recurse through connections really puts it in another class.


I used it over the last few weeks and it quickly turned into one of my favourite tools. Thank you for your work


Thanks for no account and not doing subscription


Great website, very informative, I'm going to set it up on the weekend!


Is there a way to share a users connection library to a whole team?


You can go to Settings -> Synchronization and enable the remote git repository sync. If your team members synchronize with the same remote repository, this should effectively allow for a team collaboration.


How is this different from a fancy winscp ?


On a fundamental level, the difference is that winscp is based on certain protocols like SFTP and ships their own SSH implementation for that. XPipe uses your existing ssh CLI client to accomplish the same thing instead. This makes it more flexible as it integrates with your SSH local config out of the box. This also allows you to use any arbitrary terminal emulator to open connections, in contrast to WinSCP.

But there's also much more included in XPipe that you can't find in WinSCP. There is SSH tunnel support, container support like for docker, dynamic root elevation in a file browser session without having to restart, a scripting system, a VNC viewer, an RDP launcher, and more.


Look 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.


> I do not consider Yubikey to be "commercial" feature - I use with my private computers.

Unpopular opinion - if you have information on your private computers that's sensitive enough to warrant a yubikey then you most certainly would WANT to pay a company to ensure the software is well maintained. Did you balk at the price of a yubikey when you made that purchase?


A Yubikey is very convenient to use to carry around keys between several computers in a relatively safe way. One can use it because of its practical side rather than because they have super sensitive data on their home computers.


The "free" in free software is not related to what you would pay to have it maintained.


Alright 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.


I 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#/clus... .


Yeah the Proxmox limitation originally came about because I didn't find a reliable way to detect enterprise use from the CLI (But I had not used Proxmox before implementing that, so I might have missed it).

But if I see this correctly, I could call the API from the command-line with this: https://pve.proxmox.com/wiki/Proxmox_VE_API#Using_'pvesh'_to... and check the response. If that is possible I can definitely change that limitation.


To the latter point: yes, and each API page contains both the HTTP endpoint to curl and also the pvesh command to run


Same for Amazon Linux and Azure/EKS and AKS. I would understand if this were targeted towards a general consumer, but if it's targeting techies then precluding two of the biggest cloud services in the world is... certainly a choice.

Doubly so on Yubikey/GPG/PKCS11 support. Enhanced security should never be behind a paywall, IMO.

A better approach might be number of machines instead of this detection.


The original idea was that since the systems you listed usually cost quite a bit of money to run, these would primarily be run in an enterprise context. I don't think I could afford hosting a managed kubernetes cluster and multiple decent servers in Amazon or Azure for personal use.

The Yubikey security argument is fair though, I will reconsider that.

The number of machines detection has been on my TODO list for a while, but it's a little bit tricky to implement with the current implementation.


This is a challenging thing to get right. It's interesting seeing your back and forth with the other commenters on here.


I think you're good wrt the AWS/EKS cloud stuff fwiw. You'll always have beggars coming.

If the user can afford the enterprise costs of those, they can certainly afford paying for xpipe?

Discount for individuals actually managing their own infra sounds like a reasonable place to draw the line.

Probably a lot of shadow IT around where the employer pays for all the big cloud stuff and employees either can't or won't bother getting the software side of their work tools paid for.

(As for me, I'm one of those annoying FLOSS maximalists so I won't be interested without the source under a reasonable license and I'm able to compile it locally without spending a week spelunking in undocumented build scripts. But hey, I wish you the best and don't be afraid to charge properly. It's easier to lower prices than raise them if you catch my drift)


Same, I also use Yubikeys for personal use.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: