As you might have noticed, the examples disabled authentication and ssl. This is probably a bad idea if you want to run this on a production environment. In this post I’ll describe some easy steps to secure it a bit more. If you want to have a more permanent solution, you can read more about integrating into LDAP for example in the links below. For now, I’ll describe a simple solution which should be secure enough for a temporary setup.
The last posts left us with a command line something like this:
java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1098 -Djava.rmi.server.hostname=10.200.1.122 -jar BattleBugs.jar
First, lets enable authentication again: The
-Dcom.sun.management.jmxremote.authenticate=false parameter as used can be removed, or explicitly set to
It will now complain about a missing password file:
Error: Password file not found: /opt/java/jdk1.7.0_21/jre/lib/management/jmxremote.password
There is a
jmxremote.password.template provided but that one only contains a lot of comments. Also, most likely you’re not allowed to write in that directory if this is your production environment. So we’ll create our own password file. You can go all the way and create specific user accounts or connect it to LDAP. But, for a temporary solution it’ll be enough to simply protect profiling with a password. For that, it is sufficient to create a simple password file and assign passwords to the default roles.
jmxremote.password file with the following content:
monitorRole somepassword controlRole someotherpassword
You can now start your app with an additional parameter:
VisualVM will ask for a password when you try to login with one of those two roles. Note that if you want to make snapshots or change settings, you’ll need the
Next, you’ll get a warning that no SSL is available, meaning your credentials would be sent in plain text across the network.
If you want to enable ssl, you’ll have to setup a keystore. I’ll leave that for another blog post :). In my case, the JVM itself is only locally available. To reach it from a remote location, I’m using an ssh tunnel, so I don’t require JMX to run over SSL.
You might get the following error when starting up with the password file:
Error: Password file read access must be restricted
In this case, a simple
chmod 600 jmxremote.password will help (or the Windows equivalent of it).