Allow users to bypass certificate validation about sshx HOT 4 OPEN

Well that explains why I didn't find anything!

It wouldn't really help in this case unfortunately since this environment has no independent CA and no current plans to implement one.

While supporting additional CAs is also a good idea, I'd argue that it also makes sense to allow the user to bypass certificate checks for sshx completely if they know what they're doing, much like curl does.

VPN isn't the only use case for this, the connection could also be happening over an SSH tunnel for example, or it could be running on localhost, serving https externally but with no plans to accept external sshx clients. Simply put, it would add a lot of useful flexibility.

from sshx.

I got it to work decently, I think.

I set up caddy on the node running sshx-server and simply told it to:

[vpn-dns]:443 {
    tls internal
    reverse_proxy [vpn-ip]:8080
}

This works with the caveat that the sshx binary itself will refuse to connect to https://[vpn-dns] since the certificate is self signed. Therefore, when connecting you need to make sure you're using regular http:

sshx --server http://[vpn-dns]:8080

Since this isn't the URL you want back in your response link, you also need to run the server component with --override-origin like this:

sshx-server --listen [vpn-ip] --port 8080 --override-origin "https://[vpn-dns]"

The response given when running sshx then correctly has [vpn-dns] in the link.

In summary, I guess a very minor feature request could be to add an --insecure flag to sshx as it would make setup a bit easier.

from sshx.

I'm experimenting with self-hosting sshx-server, which doesn't seem to be documented from what I can find

It is actually mentioned in the README that this is unsupported!

Glad you were able to get it to work for your use case though. Trusting self-signed certificates seems like a reasonable option to have for now. Would #31 fit your use case?

from sshx.

Makes sense!

from sshx.