Issue connecting to Ghidra server through SSH tunnel

[petekubiak]

Hi, I'm setting up a Ghidra server for remote collaboration. I have a feeling that maybe I've over-complicated it for myself in an attempt to be secure, but it seems to be so close to working that I thought it was worth sharing to see if I can iron out the last few wrinkles.

The setup

• The server is set up on my server machine with default configuration.
• The server's SSHD is configured to listen on port 2222
• Password authentication is disabled, SSH keys are instead used for authentication
• I've reserved a local IP address on my router and enabled port forwarding for port 2222 to that address

Connecting

When connecting from the client machine, I first set up an SSH tunnel for the Ghidra ports:
ssh -N -L 13100:localhost:13100 -L 13101:localhost:13101 -L 13102:localhost:13102 -p 2222 <user>@<server-address>

Then I start the Ghidra client, and in the server properties dialog I provide "localhost" as the server name and "13100" as the base port.

I have tried this from a client machine on the same network as the server, and it connected successfully.

Trying the same thing from a remote client however doesn't work. The "connecting" dialog box will appear and remain for some minutes, but eventually I get an error stating that it was unable to connect to localhost:13100.

I ran the client with VMARGS_LINUX=-Djavax.net.debug=all in the launch.properties and I can see a significant amount of traffic, including ServerHello and ClientHello messages. These seem to come in bursts with gaps in between.

From an untrained eye, it appears that there are multiple attempts being made to connect, with some information being exchanged, before the interaction inexplicably ceases. After a few attempts I eventually see the error message.

I had hoped to use the key-authenticated SSH tunnel to avoid exposing the Ghidra ports to the public internet and provide an extra level of security, but maybe this is considered overkill. Still, it feels like I'm almost there, so does anyone have any suggestions about ways I might get this working from clients on remote networks?

[dev747368]

Have you tweaked the server.conf at all?

Have you tried setting the -ip <hostname> value to something? If I remember correctly, this controls which hostname/ipaddr the server gives to the client after it connects, which the client will use to open additional connections to the server.

[petekubiak]

Sorry, I didn't spot that you'd replied to this. I found what I think is a very similar solution to the problem, so I'm going to outline the root cause and what my solution was in case this is helpful to anyone else. I'd be very interested to know if what you're proposing would have the same effect, and whether either is preferable.

Also please excuse any incorrect nomenclature I use here, I'm not a java expert 😅

The root cause

The cause of the issue was the java.rmi package. If otherwise unspecified, the RMI package attempts to get the IP address of the machine it's running on and supplies that as part of the path to its endpoints. What it will get is the IP address on the local network, which is fine if the client machine is also on the local network.

For a remote client using the SSH tunnel I described the initial handshake worked as intended, but when the client tries to access the RMI it uses the server's local network IP address rather than the SSH tunnel.

The solution

I added the following to my server.conf file:
wrapper.java.additional.8=-Djava.rmi.server.hostname=localhost
This then means that the client attempts to access the RMI at the localhost, which gets routed through the SSH tunnel and ends up in the right place.

Would setting wrapper.app.parameter.X=-ip localhost have the same effect? If so, would this be considered "cleaner", as I presume you would be allowing the app to specify the hostname rather than changing settings in the underlying java layer directly.