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

Feature Request - IP caching option to save my self-hosting behind #71

Open
Lockszmith-GH opened this issue Aug 2, 2023 · 11 comments
Open
Labels
enhancement New feature or request

Comments

@Lockszmith-GH
Copy link

A couple of quality of life related features that came up to me while I was troubleshooting local DNS issues.

Feature 1a:

Add a field in SSH connection (as well as tunnels) to enter an optional IP Address for a connection.
Add a right-click option to connect using IP Address instead of hostname.

Feature 1b:

Add an auto-update/cache switch, which will be ON by default.

When the switch is on, it will update the field with the latest successful connected IP address
To auto-update the latest successfully connected IP address.

This will allow Feature 1a to be avialable in case of DNS failing to resolve an IP.

Feature 2:

Can be combined or as an alternative to both 1a/b - if DNS resolution of the connection's hostname fails, prompt for a temporary hostname/IP Address to retry the connection with.

Use case:

I've just messed up my local DNS, which is hosted on one of the machines I reach out to via XPipe,
This seems like a common enough issue for self-hosters tinkering with environments.

I've never seen this done before, but with XPipe it suddenly made sense to me.
If it's unreasnoble, feel free to close this FR.

@crschnick
Copy link
Member

Ok, so just that I understand the problem correctly, you messed up your DNS and want to use IPs instead of host names for your ssh connections?

But you don't want change manually between IPs and host names in the configuration window and instead want to be able to provide fallback IPs/host names that will be tried when the previous ones don't work? I.e. instead of having a single text field for the host entry, have one that allows to provide multiple entries?

@crschnick crschnick added the enhancement New feature or request label Aug 2, 2023
@crschnick
Copy link
Member

Furthermore, now that the XPipe 1.5 staging version supports importing hosts from ssh configs, would such a solution work for you: https://unix.stackexchange.com/a/454743

@Lockszmith-GH
Copy link
Author

You understood my request correctly.

That's intersting, I can play with it - this does make configuration more cumbersome. Compared to my idea where XPipe keeps track of the latest IP address, and auto-updates it.

Thanks for the quick response, and for the tip.

@crschnick
Copy link
Member

The technical implementation for such a thing would be quite difficult:

  • How do we check whether DNS resolution fails (which command) on all supported operating systems?
  • How do we define a failure? What if the DNS points to a wrong server which can be resolved? What if it points to the correct server but that one is currently not reachable via SSH?

Now I haven't tested this, but due to XPipe just straight a passing your configured command to your shell, you can in theory embed shell expressions into your hostname. If you are using a posix shell and pass $(...) in the host argument, this can dynamically evaluate the expression. So if you use such an expression to evaluate to either the host name if it can be resolved or the IP otherwise, this should properly build the ssh command and achieve what you're looking for.

@Lockszmith-GH
Copy link
Author

...you can in theory embed shell expressions into your hostname...

That's a problematic idea - sanitation of values is an important security topic, and allowing that should be diswaded.

I get your point, about the comlpexity, and I thank you for entertaining the notion.

How about just fetching an IP address if the 'additional addresses' is empty.
No need for a specific command, just use a Java call.

This should remove the complexity of detection later on.

@crschnick
Copy link
Member

I understand your concern about the sanitation of inputs. The reason this is currently allowed is that the user should be in full control over what values are entered in there. If somehow an adversary is able to modify your own configuration and embed expressions in it, you might have bigger problems. All inputs are properly sanitized at other locations, e.g. the file browser, I just left that in to give users more flexibility.

The problem with DNS resolution via a Java method is that it would always resolve that using your local configuration. If your SSH connections have set a proxy/gateway, that DNS resolution does not match the one on the proxy machine.

It would be nice if SSH would be able to provide the IP it last resolved when connecting via a hostname, but I don't think it can tell you that.

@Lockszmith-GH
Copy link
Author

I see your point. So if you chose this, you'll need to implement at least 3 separate methods:
Linux - dig or nslookup
Windows - powershell resolve-dnsname or nslookup.ex
MacOS - #... I have no experience#

figuring out what is avialable, parsing the output - and dealing with this as these systems evolve.

Better drop the auto-detection part.

@crschnick
Copy link
Member

So I will see what I can come up with in the future. Out of all the things that I currently have on my to do list, this isn't very high right now though.

@Lockszmith-GH
Copy link
Author

Really appreciate you entertaining my idea, even on a low priority.
Thanks for making this tool a thing.

@crschnick
Copy link
Member

I was thinking about adding a system information button for connections to display basic information, including things like the IP address. That information would be kept from the last successful connection attempt, this would also make solving your problem easier as you then could just copy that IP and it temporarily use it as the host address for the connection. Would that work?

@Lockszmith-GH
Copy link
Author

yes, that's not bad at all. Although it would still mean editing or creating a separate connection, but at least the detail is preserved somewhere. Thanks for thinking about solving this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants