I recently reinstalled my desktop with Fedora 23, and found the need to “fix” the way Firefox launches files with .jnlp extensions.  In many cases it is merely sufficient to install the icedtea-web RPM package using:

$ sudo dnf install -y icedtea-web

However, as is the case with many java based applications, this is typically not sufficient. Particularly when looking at out of band management interfaces for various vendor hardware, e.g. Dell’s iDRAC interfaces are notoriously difficult to get working out of the box on Fedora based systems.

I recently stumbled on the following which got me about 99% of the way to having the iDRAC console links work correctly:

https://stuffivelearned.org/doku.php?id=apps:firefox:jnlpfix

Though I did find a small issue with the very last part of the instructions.  I’m including the content here (in the off chance that the link should go stale and I’d like to preserve the knowledge being shared). Content is somewhat abridged.

Open Your Profile’s Mimetypes File

cp mimeTypes.rdf mimeTypes.rdf.save

 <RDF:li RDF:resource="urn:mimetype:application/x-java-jnlp-file"/>

  <RDF:Description RDF:about="urn:mimetype:application/x-java-jnlp-file"
                   NC:fileExtensions="jnlp"
                   NC:description=""
                   NC:value="application/x-java-jnlp-file"
                   NC:editable="true">
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-java-jnlp-file"/>
  </RDF:Description>

Below that, add this:

  <RDF:Description RDF:about="urn:mimetype:handler:application/x-java-jnlp-file"
                   NC:alwaysAsk="false"
                   NC:saveToDisk="false"
                   NC:useSystemDefault="false"
                   NC:handleInternal="false">
    <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/x-java-jnlp-file"/>
  </RDF:Description>

Almost done, one more section to add:

<RDF:Description RDF:about="urn:mimetype:externalApplication:application/x-java-jnlp-file"
                   NC:path="/path/to/external/script"
                   NC:prettyName="some-name-here" />
</RDF:Description>

So in my case, I created an external script in my home directory which in turn calls javaws. The reason for this is that in the case of the Dell iDRAC interfaces, the .jnlp files have long filenames which include numerous characters which cause issues with the call to the external program.  For example, you may find the filename may look something like this:

/tmp/mozilla_kambiz0/viewer.jnlp\(some-idrac-fqdn-goes-here@0@idrac-1234567\,+PowerEdge+R620\,+User_+root@145519812345@ST1\=002f4511d94638eaaabbb80bb6642bda\)

So I ended up using the path: /home/kambiz/bin/Java-Web-Start (and the prettyName of “Java-Web-Start“).  Make the Java-Web-Start an executable script (mode 755) with the following content:

#!/bin/sh

tmpfile=`mktemp /tmp/javaXXXXXX.jnlp`
cp "$1" $tmpfile
javaws $tmpfile
rm -f $tmpfile

One last thing remains to do to ensure Java launches correctly:

cp .config/icedtea-web/security/trusted.certs ~/.java/deployment/security/
cp .config/icedtea-web/security/trusted.jssecacerts ~/.java/deployment/security/

That should do it!

Thanks Will Foster!

Many online services (google, facebook, etc), as well as company VPN configurations require the use of OTP (one-time password) for improved security. The one-time password is comprised of a PIN (which is static and only known to you in your head), as well as a software or hardware token.  For more information on various implementations of two-factor auth, see:  https://fedorahosted.org/freeotp/ or https://github.com/google/google-authenticator/wiki .

Before I go any further and detail how you can generate OTP on a Linux box, let me state very clearly, doing the following is NOT RECOMMENDED if you are concerned with SECURITY.  I do this as a matter of convenience, and also because I am comfortable with the level of additional security measures I take on my personal laptop.

Why is it not recommended you ask?  I’m glad you asked, so please let me explain.  If your laptop or desktop is somehow compromised, and someone can intercept your activities, and you use your laptop to generate as well as enter your one-time password when connecting to remote resources, the attacker will then have not only the static PIN associated with your OTP, but will also have a token generated (since it also resides on your laptop in software).  As such, your token generator should typically NOT reside on your laptop.  Some people also make use of the YubiKey harware token generator, which they leave plugged into their laptop all the time, and just press the hardware button to enter the OTP into an application with focus.  In my opinion, the convenience of using the YubiKey reduces security in much the same way as having the soft-token running on a laptop or desktop, as physical access to your system now means an attacker simply needs to employ a brute-force attack against a set of static passwords.

With the above in mind, the following method is used on a Fedora22 laptop using the Oath Toolkit.

First, install the oathtool RPM using:

yum install -y oathtool

Next, generate your token.  I won’t detail how this is done here, as it will be dependent on service provided.  Typically you’ll see a QR code that can be scanned into one of a number of available clients for mobile platforms.  However, the QR code is really just a representation of the token secret associated with your token.  There may also be a URL that can be used with various clients to initialize the token generator.  This URL will look something like:

otpauth://hotp/SomeTokenName?secret=base32-encoded-secret&counter=0
or
otpauth://hotp/SomeTokenName?secret=base32-encoded-secret&counter=0

Next, take the “base32-encoded-secret” (note that this will seem like a random string of characters), and store it in a GPG encrypted file.  I used the file $HOME/.google_token.gpg as an example.

If you’re using a counter or event based (HOTP) mode, you will also want to store the counter used.  For this I use $HOME/.google_counter file.

Finally, use the following Bash script to generate your OTP:

#!/bin/bash

counter=$(cat ~/.google_counter)
counter=$((counter+1))
secret=$(gpg < ~/.google_token.gpg) 
oathtool -c $counter -b $secret echo $counter > ~/.google_counter

IMPORTANT: In order to protect your laptop and the contents therein, please use disk encryption so that if your laptop or desktop is ever stolen your files will not be readable by anyone unless they have the decryption key.  The combination of disk level encryption, as well as the use of GPG to further encrypt the secret associated with my token is why I am comfortable with the above approach.  However, you will need to consult with your local security policies in order to ensure that your are within the guidelines provided by your company or institutional Information Security group.

My friend Will Foster recently turned me onto blogging.  It’s a fantastic way of sharing information with like-minded individuals.  I’m not sure how often I will post anything here, or frankly what specific things I’ll post about.  I will try and give it a try, but meanwhile, for lots of interesting blog posts about technology, comedy, and cooking, see Will’s posts here:   http://hobo.house/

Thanks Will Foster!