Remote Consoles

As part of my job of doing system administration for the Fedora Project’s Infrastructure, I often need to connect to the remote console that most servers have available via their Out Of Band management cards, like the Dell iDRAC, IBM IMM or the HP iLO.

Unfortunately, these remote consoles pretty much always use JAVA for their remote console, and their security environments are pretty much always less than ideal. So over the years, I’ve had to make various of these cards work with the default Fedora JAVA installations, and this page is a collection of notes to myself, and others interested, on how to get them working.

NOTE: Be warned that most of these notes will decrease the security of the JAVA installation! I would strongly advice to revert any made changes right after you are done. I do NOT want to be held responsible if your machine gets compromised because you didn’t follow this advice.

Dell iDRAC7

These are some of the least broken devices. First note that if you upgrade their firmware to 2.0.0 or higher, you will have an HTML5 console option available, bypassing the need for JAVA entirely! If you do need to use the JAVA console for some reason, it might look like it will start normally, but then suddenly stop with “Connection Refused”. This is an incorrect message, but it comes down to that the JAVA applet it ships is looking for the Certificate Authority certificates at a specific location. To fix this, run these commands:

mkdir -p ~/.java/deployment/security
ln -s /usr/lib/jvm/java-*/jre/lib/security/cacerts ~/.java/deployment/security/trusted.certs

What this does is just create the directory the iDRAC JAVA applet looks for the trusted CA list and links the system list there. This one does not expose your installation to more danger, and is one you could keep in place.

HP iLO2

Now, for some reason, this one does not like TLSv1.1 and higher, so you will need to disable that. This is indicated by a ClassNotFoundError of remcons.class. For this one, we are going to have to disable TLSv1.1 and TLSv1.2 in JAVA, to do that, do the following:

Open /usr/lib/jvm/java-*/jre/lib/security/java.security. in your favorite editor.
Search for certpath.disabledAlgorithms, and delete everything except MD2.
Search for tls.disabledAlgorithms=, and replace all the text so it look like:
tls.disabledAlgorithms=TLSv1.1,TLSv1.2

This disables recent TLS versions and re-enables some disabled, insecure, algorithms, so you do want to revert this when you are done.

IBM IMM

The IBM Integrated Management Module (IMM) requires a change like the HP iLO2 one, except that you can just remove everything after the =-sign for tls.disabledAlgorithms.

This one is also insecure, and should be reverted afterwards. I will fill this one with more details when I find my notes on this back.

IBM OpenBMC

The IBM OpenBMC requires a separate change to the allowed algorithms. This time it’s to the jdk.jar.disabledAlgorithms setting, since IBM has signed the JARs with MD5.

You will notice that you need this workaround because the Java console will show errors like “Cannot grant permissions to unsigned jars”, which is caused by the JRE silently ignoring the signature.

To fix this:

Open /usr/lib/jvm/java-*/jre/lib/security/java.security. in your favorite editor.
Search for jdk.jar.disabledAlgorithms, and delete the MD5 entry from there.

This re-enables an insecure, old hash method for verifying JAR signatures, so you do want to revert this when you are done.

Others

Most other cards will require changes much like the HP iLO2/IBM IMM ones, re-enabling insecure algorithms, and when I come in contact with them again, I will add those.