Issue Details (XML | Word | Printable)

Type: New Feature New Feature
Status: Open Open
Priority: Blocker Blocker
Assignee: visualvm-issues
Reporter: bjb
Votes: 5
Watchers: 1

If you were logged in you would be able to see more operations.

SSH tunnel plugin

Created: 23/Jul/08 06:19 AM   Updated: 02/Nov/12 01:20 PM
Component/s: plugins
Affects Version/s: 1.0
Fix Version/s: not determined

Time Tracking:
Not Specified


Issuezilla Id: 168
Participants: bjb, jsedlacek, scoopex and visualvm-issues

 Description  « Hide

At this time VisualVM (as JConsole) because of JMX&RMI issues are
is not working behind SSH.


Most production machines are nowadays only accessible thru a SSH layer (because
beeing in protected areas in white rooms). Not having a SSH friendly solution
means, not beeing able to supervision most environment.

This is blocking because there is no way at this time to workaround the
situation, thus preventing anybody to use VisualVM on such environment.

scoopex added a comment - 02/Nov/12 01:20 PM

Still waiting for this feature.

There is a workaround (see - but with this settings it is not possible to use the VisualGC plugin (which needs jstatd connectivity).

Using VisualVM on remotehosts behind a firewall ist still a real pain!

scoopex added a comment - 10/Jan/12 03:43 PM - edited

From my point of view it would be a cool thing to have the possibility to run visalvm divided in two processes:

1.) The backend

  • runs at serverside
  • connect to local procces ids via vm.attach()
    (for security reasons this would be a nice thing in production environments - only users with acces to that
    process/user can connect - no extra jmx account management)
  • provides access to all jvms(pids) which run on this system
  • analysis at serverside

2.) The frontend

  • runs on the developer workstation
  • displays data and interacts with the user
  • opens a ssh channel, uploads the backend to /tmp/visalvm-<randomkey>, executes the backend, communicates
    over stdin/stdout with the server process
    => Support for SSH Keys would be good
    => Support for jumphosts would be great (workstation --SSH--> jumphost ---SSH--> production machine)

It seems that only via vm.attach(<process-id>) the full features of visualvm are that correct?

scoopex added a comment - 14/Mar/11 11:14 PM

I also experienced this problem. Typically i use the following commandline to tunnel to a remote server (firewalls typically do not permit access to hosting areas):

ssh -L 10001:

This command tunnels port 10001 of the remote system to my local system ( port 10001.

Visualvm rejects to open a jmx connection to port 10001 with a notification that "...localhost is already monitored..."
It seems that the logic for detecting duplicate connections should improved.

You can workaround this problem using a socks tunnel:
(but this is not available for every ssh client)

1.) Connect to server
ssh -D 10002
2.) Execute Visualvm on your workstation
./visualvm -J-Dnetbeans.system_socks_proxy=localhost:10002

It also seems that some features (i.e. tracing) are nit available using jmx connections over network.
A great advantage would be a tiny remote server daemon which utilizes the java vmattach api (access via process id)
and exposes access to all jvms over network. A new connection type in visualvm opens the connection to this daemon.
running on this host. This connection can be tunnelled via SSH or exposed over a single port (then we need authentication and encryption) - probably we do not need a new communication protocol and use the existing.....

I think comfortable remote access is essential for making visualvm to be the most popular java-profiling-tool )

jsedlacek added a comment - 01/Jul/09 09:56 AM

Could you please be more specific on what exactly doesn't work for you?
Also, could you please describe how would you like the VisualVM to support the
SSH tunelling? Thanks.