[HN Gopher] Show HN: XPipe, a brand-new type of remote file brow...
___________________________________________________________________
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!
Author : crschnick
Score : 42 points
Date : 2024-06-06 16:34 UTC (6 hours ago)
(HTM) web link (xpipe.io)
(TXT) w3m dump (xpipe.io)
| vzaliva wrote:
| 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.
| crschnick wrote:
| 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.
| philsnow wrote:
| 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... .
| mynameisvlad wrote:
| 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.
| crschnick wrote:
| 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.
| crschnick wrote:
| 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.
| philsnow wrote:
| To the latter point: yes, and each API page contains both
| the HTTP endpoint to curl and also the pvesh command to run
| theogravity wrote:
| Same, I also use Yubikeys for personal use.
| mbesto wrote:
| > 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?
| cobbal wrote:
| Reminds me of tramp-mode, but without being stuck in emacs. Nice!
| crschnick wrote:
| 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.
| erksa wrote:
| 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.
| comagoosie wrote:
| 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.
| throw46365 wrote:
| 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.
| eigenvalue wrote:
| 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.
| crschnick wrote:
| 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.
| eigenvalue wrote:
| 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?
| preezer wrote:
| Finally... I looked out for such an product for years... I
| definitely try it, tomorrow.
___________________________________________________________________
(page generated 2024-06-06 23:00 UTC)