How to connect localhost-URLs through SSH Secure Gateways?
Hi everyone,
I'm accessing lots of web-UIs behind customer routers, firewalls etc. using setups with some SSH Secure Gateway. The config for the SSH Secure Gateway takes care of SSH username, private keys, passwords etc. and is configured in dynamic mode with some randomly chosen port. Multiple sessions reference that SSH Secure Gateway to automatically create a session as necessary.
The important thing to note is that individual sessions use URLs like https://192.168.0.1:6443 or http://192.168.0.10:80 etc. I don't need to care about which ports the SSH Secure Gateway uses, but simply need to configure that the SSH secure Gateway is used per session. That works easily in all cases where I don't need to access localhost, but when trying to use that, the SSH Secure Gateway doesn't seem to be used anymore.
The problem is that I have some setups where I connect using SSH to some server and and that server hosts web-apps on e.g. http://localhost:8080/webapp1, /webapp2 etc. Creating a session like all other non-localhost sessions before with using localhost doesn't work. It seems like the SSH Secure Gateway is not used in those cases. Changing the web server to listen on some non-localhost private IP additionally and configuring that private IP in the session makes things work instantly. Pretty much like with the former examples of :6443 and :80. Though, I would like to avoid listening on more than localhost, for security reasons, it's simply not needed.
I'm able to access http://localhost:8080 only when not using a SSH Secure Gateway with dynamic setup, but a static port forwarding using some random local port and 8080 remote. In those cases I need to configure http://localhost:RANDOM_PORT in the session and things in general work like with PuTTY in the past.
Am I missing something or is localhost handled specially?
I would have expected SSH Secure Gateway itself don't matter too much about private IPs vs. localhost. If the SSH endpoint sits on some server hosting some web-apps, localhost should simply work form the perspective of the SSH tunnel endpoint.
Thanks!
All Comments (12)
Hello,
I verified with the engineering team and the issue may be related to the IPv4 or IPv6 resolution. Could you try with either 127.0.0.1 (IPv4) or ::1 (IPv6) to see if it helps.
It is also possible that there is an issue with the connections to localhost, it is on his to do list to verify it.
Best regards,
Richard Boisvert
While "localhost" in deed resolves differently, e.g. [::1] locally and 127.0.0.1 remotely, I already tried with setting everything to 127.0.0.1. I as well made sure using some viewer for open TCP connections that the local tunnel endpoint is 127.0.0.1 on my machine, that Tomcat on the remote server is 127.0.0.1:8080 etc. Still no luck. Using Process Monitor from Sysinternals I can see that a tunnel is established, what I don't see is any connection attempt of the session using the secure gateway.
[30.06.2022 08:47:48] Connecting to port: 12321 (IP any) [30.06.2022 08:47:48] SSH banner: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.7 [30.06.2022 08:47:48] Sending kex init [30.06.2022 08:47:48] Received kex init [30.06.2022 08:47:48] Selected algorithms: curve25519-sha256, ssh-ed25519, chacha20-poly1305@openssh.com, chacha20-poly1305@openssh.com, implicit by cipher, implicit by cipher, none, none [30.06.2022 08:47:48] Sending Ed25519 kex init [30.06.2022 08:47:48] Received Ed25519 kex reply [30.06.2022 08:47:48] Successfully authentified server [30.06.2022 08:47:48] Sending new keys message [30.06.2022 08:47:48] Sending userauth service request [30.06.2022 08:47:48] Received new keys message [30.06.2022 08:47:48] Received extension info message [30.06.2022 08:47:48] Server accepts public key types: ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 [30.06.2022 08:47:48] Received service accepted message [30.06.2022 08:47:48] Using provided key data [30.06.2022 08:47:48] Sending userauth init request [30.06.2022 08:47:48] Received userauth failure: publickey,password [30.06.2022 08:47:48] Starting authentication by key [30.06.2022 08:47:48] Validating public key: rsa-sha2-512 [30.06.2022 08:47:48] Received userauth key ok [30.06.2022 08:47:48] Sending userauth public key signature: rsa-sha2-512 [30.06.2022 08:47:48] Received userauth success [30.06.2022 08:47:48] User authenticated successfuly by public key [30.06.2022 08:47:48] Listening on 127.0.0.1:13346 D [30.06.2022 08:47:48] Received global request: hostkeys-00@openssh.com , no need to reply
Afterwards I start the session within RDM and either there aren't any additional log statements in that windows anymore and the session only shows the following error message:
The Page Failed to Load A connection attempt was refused. To customize this message, please handle the WebView's LoadFailed event and then Set e.ErrorMessage in your event handler based on e.ErrorCode, or call e.UseDefaultMessage if you just wish to display the error message without this help message.
Or sometimes I see the above error message, but some additional logs for SSH as well:
[30.06.2022 08:50:02] Sending forward channel open request: 0/- update.googleapis.com:443 [30.06.2022 08:50:02] Received channel open confirmation: 0/0 WS 200000/2097152 MPS 32000/32768 [30.06.2022 08:50:02] Successfully established connection 127.0.0.1:13346 -> update.googleapis.com:443 [30.06.2022 08:50:15] Sending channel EOF: 0/0 [30.06.2022 08:50:15] Received channel EOF: 0/0 [30.06.2022 08:50:15] Sending channel close request: 0/0 [30.06.2022 08:50:15] Received channel close request: 0/0 [30.06.2022 08:50:15] Channel is closed: 0/0 [30.06.2022 08:50:15] Closed tunnel: 127.0.0.1:13346 -> update.googleapis.com:443
This looks like the configured Chrome browser for that session does something on its own and successfully transfers over the tunnel. Most likely because neither localhost nor 127.0.0.1 nor [::1] are used. I have the feeling that RDM detects cases like 127.0.0.1 and simply doesn't forward traffic over the tunnel in those cases.
Some additional evidence for that: The tunnel established by RDM is available not only for RDM itself, but for every SOCKS compatible application I use outside of RDM, e.g. on the shell. So I tried to access the website manually using CURL and this worked. I see downloaded HTML on the shell AND some corresponding logs in RDM's SSH window.
[30.06.2022 09:04:32] Sending forward channel open request: 0/- 127.0.0.1:8080 [30.06.2022 09:04:32] Received channel open confirmation: 0/0 WS 200000/2097152 MPS 32000/32768 [30.06.2022 09:04:32] Successfully established connection 127.0.0.1:13346 -> 127.0.0.1:8080 [30.06.2022 09:04:32] Sending channel EOF: 0/0 [30.06.2022 09:04:32] Received channel EOF: 0/0 [30.06.2022 09:04:32] Sending channel close request: 0/0 [30.06.2022 09:04:32] Received channel close request: 0/0 [30.06.2022 09:04:32] Channel is closed: 0/0 [30.06.2022 09:04:32] Closed tunnel: 127.0.0.1:13346 -> 127.0.0.1:8080
The corresponding shell:
C:\Users\tschoening>curl --location -x socks5h://127.0.0.1:13346 http://127.0.0.1:8080/PavonisAdmin
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<META HTTP-EQUIV="Refresh" CONTENT="0;URL=pages/restricted/administration/admin.xhtml">
<head>
<title>Governikus DATA Pavonis</title>
</head>
</head>
<body>
<p>Loading ...</p>
</body>
</html>
C:\Users\tschoening>Habe a look at the used hosts and ports: It's 127.0.0.1 in both cases and the port of the requested website is :8080, not the tunnel endpoint or alike. That is exactly like expected when using a SOCKS proxy. OTOH, that same configuration simply doesn't work from within RDM for some reason, neither as SSH Secure Gateway nor as manually configured SOCKS proxy in the session. It really seems that RDM ignores the tunnel when 127.0.0.1/localhost/[::1] gets requested as target. Though, it doesn't do so when configuring a port forwarding instead of a SSH Secure Gateway/SOCKS proxy. Looks to me like there's some automatic preventing my use-case.
I've did some additional testing and had a look at Wireshark and whenever I open my web browser session in RDM, the connection attempt is from some port around 6108X to 8080 on localhost. The source port is simply increasing, started with ...80, was ...81, ....82 etc., shouldn't matter too much. But the destination was always the same, 8080, even though from my understanding it should be the local tunnel endpoint port 13346.
I have Tomcat set up on my own system with http://127.0.0.1:8080/PavonisAdmin as well for test purposes. Though, most of the time it's disabled. Guess what heppens when I enable my local Tomcat? :-) Correct, I see THAT web interface in the RDM session. That explains why the connection attempt fails without my running Tomcat as well, RDM simply doesn't forward through the tunnel for some reason. I've attached my failing config so you might have a look. But keep in mind that I successfully use those approaches for other web-UIs, the only difference really is that those use 127.0.0.1 as the destination, but some other private IP.
SSH Secure Gateway (LXP).rdm
PavonisAdmin (Gateway).rdm
PavonisAdmin (Gateway) (SOCKS).rdm
Hello,
I have forwarded all the information to the engineering team; we will inform you of their findings.
Best regards,
Richard Boisvert
Hello,
Could you confirm what type of website entry you are using to connect to the URL? If it is not Chrome, it will most likely not worked. The embedded Chrome is the only one with a valid Proxy section to specify the tunnel information.
Best regards,
Richard Boisvert
It is Chrome, that's why attached all the configs, so you might have a better look at the details yourself.
Hello,
I am verifying with our IT team if we have the equivalent of your setup in our lab.
In the meantime, under the VPN/SSH/Gateway > Settings (SSH) of the Web Browser entry, could you try to check the "Use dynamic port" and see if it helps?
Best regards,
Richard Boisvert
Tried that before already and right now again, doesn't work. The session still tries to connect to my 127.0.0.1 instead of running through the SSH Secure Gateway and using THAT 127.0.0.1 afterwards.
Hello,
While we are still trying to set a test environment that matches the information you have provided us so far, I just would like to validate with you the version of RDM and the type of data source that you are currently using.
Best regards,
James Lafleur
I've just upgraded to 2022.2.17.0 and things still don't work. The data source is a XML file, so that I'm able to put it into GIT/SVN.
This might sound like a weird test, but could you create a local SQLite and see if the same issue occurs?
James Lafleur
Tried, doesn't work.
PavonisAdmin (Gateway).rdm
SSH Secure Gateway (LXP).rdm
test_localhost_through_ssh.db