oppl’s blog

I had security concerns regarding the default options to run VNC-access to my Ubuntu Desktop machine. Keeping the port always open didn’t seem a good idea to me, the maximum 8-char password does not add to much security.

Using an ssh-tunnel basically seemed to provide a solution. When digging a bit into the topic, I came up with a pretty neat solution, which provides sufficient security, is flexible in terms of the used desktop environment and furthermore only uses ressources when needed.

What you obviously need is an ssh-server running on the machine you want to access. Additionally, I installed x11vnc, which is a simple VNC-server capable of connecting to every running X-Server independent from the running desktop system.

I’m remotely connecting to my machine now via a ssh tunnel. Instead of letting the VNC-Server run all the time, I only start it, when the ssh-connection is established. After waiting a few seconds until the VNC-Server is up and running, you can simply connect to your machine via a secure tunnel. In it’s default configuration, x11vnc quits as soon as the VNC connection is terminated. As a consequence, I’ve created a simple shell script on the notebook I use to connect to the remote machine:

#!/bin/bash

ssh -t -L 5900:localhost:5900 <your server address> 'x11vnc -localhost -rfbauth .vnc/passwd'&
sleep 10
vinagre localhost:5900

This script simply brings up the tunnel, starts the VNC-server remotely and then starts vinagre, the VNC-client included with Ubuntu, on my notebook. As soon as I shut down the connection, the VNC-Server is closed and the SSH-tunnel is terminated. For added security, x11vnc also asks for a password (-rfbauth). The password can be set on the server machine using “x11vnc – storepassword”. SSH is configured to work with public/private-key infrastructure to avoid being asked a password for ssh-login too (using a keychain application to unlock the ssh-key). Setting up the public key authentication is pretty straightforward.

Maybe this solution is obvious anyway but it appeared pretty cool to me – so I just wrote about it.

Finally, I made it. It has been a pretty rocky way and I struggled hard – but now I got GPG using my Fellowship Card up and running on all of my platforms.

Let me try to outline the way I took, the obstacles I encountered and how I managed to resolve all issues.

• Basically I followed the excellent new tutorial at the FSFE Wiki. Everything worked out fine – until …
• … I tried to move my newly created subkeys to the smartcard. After asking me for the passphrase for the key and the master PIN for the card, gpg always failed with the very verbose message “Allgemeiner Fehler” (and no log entry or whatsoever).
• Obviously, it (i.e. the beast inside my computer) wanted me to play around. So I did. I tried to exclude all potential issues regarding file permissions. That didn’t seem to be the problem. My hypothesis then was, that my smartcard reader (a Reiner cyberJack pinpad) wasn’t capable of writing to the card (as it also wasn’t possible to alter the PIN codes). However, that also turned out not to be the problem, because the metadata of the card (name, public key URL, …) could be altered.
• Before giving up for that day, I wanted to give GPG2 a try. So I installed the gnupg2-package on my Ubuntu 9.10 and tried to access the card. I failed, obviously because of an issue with the – then mandatory – gpg-agent. Turned out that it wasn’t able to locate its socket where it expected it to be. I found a workaround in a forum post, which I eventually tried out. Using GPG2 and gpg-agent, I was finally able to transfer the keys to my card and also to alter the PIN-codes.
• From this point on, I continued to follow the tutorial mentioned above. Everything worked out fine (except I’m missing my original encryption subkey now, which does not seem to have any negative effects).
• As GPG2 only worked using the gpg-agent-workaround, I switched back to GPG for daily use. With the keys already transfered to the card, GPG also works without flaws.
• Thunderbird Integration (via Enigmail) then was no problem anymore – worked out of the box and now requires me only to plug in my card and enter my PIN.
• As everything worked out fine on Ubuntu, I transfered my whole .gnupg directory to my Mac, where I already had a running instance on MacGPG. Also the drivers for the cardreader were already installed, as I had used it before with my Austrian citizen card. Surprisingly, everything worked immediately without any issues. Also my Thunderbird installation on the Mac was able to interact with the card.

For now, I pretty happy with the setting I have. The card reader is hotpluggable on both plattforms, Thunderbird is able to use it via Enigmail. For everything else, I’m using the terminal on both platforms at the moment.

Next task: make ssh work with the smartcard – to be continued.