SSH tunnel to HP-UX not using localhost

[jmgallag]

Hi,

I would like to use a SSH tunnel to encrypt connections to a Xvnc server on one of my HP-UX servers. I am using Exceed v14 on the client side, on the server side is:

OpenSSH_5.0p1+sftpfilecontrol-v1.2-hpn13v1, OpenSSL 0.9.7m 23 Feb 2007
HP-UX Secure Shell-A.05.00.023, HP-UX Secure Shell version

I have the Xvnc server configured to listen only on 'localhost'. The tunnel starts just fine. When the channel for the VNC client attempts to connect, the connection is refused because the channel on the server side attempts to connect to the servers real IP address, rather than 127.0.0.1.

Is there a configuration option I can use to force a localhost connection between the server end of the channel to Xvnc?

Thanks,

Jim Gallagher

[Matti_Kurkela]

I don't know how the tunnel set-up works with Exceed v14 specifically, but in general, when you specify the tunnel target using the hostname of the target server, the real IP address of the target server gets used. If you instead specify the tunnel target as "localhost", it will direct the tunneled traffic to 127.0.0.1 as seen at the remote endpoint of the SSH connection.

[jmgallag]

MK,

Not sure I understand what you're saying.

I have a tunnel running between my PC and a server. The server must be specified with an hostname or IP. The tunnel listens on localhost:5901 and attempts to establish a channel to port 5901 on the server when a client connects.

I don't see any config option in either the Exceed or the SSH man pages to force the server end of the channel to bind to  any specific interface, including localhost.

Thanks,

Jim

[Matti_Kurkela · Accepted solution]

I don't have Exceed v14 available to me and could not find a screenshot of its tunnel settings, so I'm using general SSH knowledge only.

When you make a SSH connection, you specify a server you wish to connect to.

When you add a tunnel to that connection, you specify three more things: a local port, remote hostname/IP, and a remote port.

It might seem counterintuitive to specify "localhost" as the remote hostname for the tunnel, until you realize how SSH works when setting up the tunnel.

It sets up a listening port as specified by the "local port" parameter, and then transports all the traffic connecting to that port in a "sub-channel" of the main SSH connection.The remote hostname and port are not evaluated yet at this point: no matter what you specified, your tunneled data is always going to be passed to the remote side of the SSH connection.

The remote hostname/IP and the remote port parameters are sent as-is to the remote SSH server, which will then use those parameters to set up the remote end of the tunnel. If the remote hostname/IP is specified as 127.0.0.1 (or as "localhost" or anything else that resolves to 127.0.0.1), then the SSH server will connect to the specified port at the SSH server itself.

If you specified the real hostname of the SSH server as the remote hostname for the tunnel, then the SSH server will use the real IP address of the SSH server instead of 127.0.0.1.

If your SSH client (Exceed?) only allows you to specify the local and remote port numbers for the tunnel, it has a crippled SSH tunnel implementation and you should be using something like PuTTY instead: it is free and allows you to fully specify the SSH tunnel parameters.

An example with Unix-based OpenSSH might be helpful:

I'm standing at a Linux workstation named "client". I want to connect to a https-based admin GUI at "server", but it only listens for connections at 127.0.0.1, port 2380. There is a firewall between "client" and "server" that only allows SSH connections through.

I set up a SSH connection with port forwarding like this:

client$ ssh -L 1111:localhost:2380 server

After logging in, I open a browser on the client and point it to https://localhost:1111.

(I then click through a security warning, because the SSL certificate does not match what the browser is seeing... but I expected that because of the tunnel.)

The tunneled connection now has three distinct parts:

1. the plain HTTPS connection between the browser and the SSH client process on the host "client".
2. the HTTPS-within-SSH tunnel between the "client" and "server" hosts, within a subchannel of my SSH connection.
3. another plain HTTPS connection between the sshd of the "server" host and the tunnel destination "localhost:2380" as seen by the server (i.e. port 2380 of the server itself).

[jmgallag]

MK,

Well done. On the Exceed "Edit Outgoing Port Forwarding Information" dialog, I assumed that the "Destination host" field needed to be the actual host name of the server side, but by changing this to "localhost", the channel did what I wanted and I can connect.

Thanks for taking the additional time to write the excellent description.

Jim Gallagher

Cypress, CA