Using a hardware token to log on to linux

PKI/hardware tokens are now quite a commonplace accessory in the IT workplace and are generally used to enable VPN connectivity to the office or to sign or encrypt emails. I knew they could be used to authenticate server (and even database access) but this always sounded like it was a very complex thing to do and would only ever really be appropriate in government/defence type use cases where even higher levels of access control are required.

In a conversation this week though with our security guys they were saying that's its actually very easy to do for Linux and we should look into doing it - so I did just that......

Now like many people I use the excellent PuTTY tool for Linux machine access ( I love the way the url is so very British :-)) - however it seems this natively does not support the use of hardware tokens for authentication - instead there is a fork called PuTTY-CAC which includes this functionality (as well as everything putty had up to the fork version - which is pretty much everything).

You can download the installed or just the individual executables should you so wish.

Once the file is downloaded you launch it and at first glance it just appears to be exactly the same as normal putty - there is just a small extra section shown below

 

 

Clicking (in my case) on the Set PKCS Cert opens up a file explorer window where you need to locate the dll that is used to read/write from your token - in my particular case we are using cryptovision but there are many other providers that it could be - so I browse and find C:\Windows\System32\cvP11.dll

 

Once I do that the dll is accessed and the token queried to identify my certificate

 

 

 

I then OK this one which loads it into the putty-cac configuration - the screen now shows the thumbprint in the window.

 

 

 

The nice thing now is that once this is done I can click on the copy to clipboard option and the string I need to use on the Linux box is generated exactly for me - so I click that and get something like this

 

ssh-rsa blahblahblahblah PKCS:blahblahblah=C:\Windows\System32\cvP11.dll

 

Once I have that I then choose a Linux machine I want to try this out on - in my tests I used both Ubuntu and RHEL - both of which worked without issue.

 

Now the last stage is actually very easy and if you are familiar with pki anyway (you may have used to copy between users on different Linux boxes without the need for passwords) and the hardware token version of this is no different.

 

So steps are (and first 3 only necessary if you never used keys before):

 

1) decide on the user you want to try this out on - it has no link whatsoever to the owner of the token - so you could try it as rich or oracle or even root - any of them will do - all you are doing is copying the public key of the token into an account on Linux.

2) run ssh-keygen as that user in the $HOME directory to generate some of the basic stuff required - just accept all the defaults here

3) in $HOME/.ssh create a file called authorized_keys

4) Paste the contents of the string generated from putty-cac above into the authorized_keys file

 

And that's it - ready to test (now a warning here that for me with a default server install this just worked - but I know from past experience that ssh can be very picky on the exact file/directory permissions that need to be set on everything related to ssh to ensure it is secure - so if it's not working bear this in mind)

 

So if I now with all that config in place launch putty towards my server initially everything looks the same and I am prompted for a login - now I enter rich/oracle/root (whatever I decided to test with) and this is now where it is changed - I'm now presented with a pki pin box for me to enter.

 

 

 

If I get the pin wrong I get this message and am denied access

 

Server refused public-key signature despite accepting key!

If I get it right though it logs me in just fine

And there you have it - this was really surprisingly easy and can give an ever greater amount of security to your Linux access - another nice feature of this is that if someone leaves or the token is lost the certificates can be disabled to not work - this is done via certificate revocation list (much the same as https certificates)