Securing Openssh logins with SSH Key pairs

Here is my attempt to assemble a non-bullshit guide since the interwebs are so flooded with unnecessary obscurantism concerning this subject. I favor Debian but the general traits are applicable on most Linux distributions.

Let’s begin:

What you have realized a long time ago

  • Password only logins sucks.

Mission Objectives

  • Implement Public key based authentication.
  • Generate 4096 Bit private key.
  • Optionally, Convert your private key to PKCS8 format.
  • Profit!


Public key = Resides in your home directory on the server you want to SSH to.
Private Key = Your Super secret key that you access your server with.
You unlock the key locally with the password
you supplied at the time of generation. It should be hard to steal!
But we can at least take some precautions to make it harder to crack. Still, if it get stolen and you are aware of it, generate new keys anyway.

Create the secret holy divine key file to use when you SSH to the server

Note: Due to wordpress inability to wrap your code or display vertical scrollbar when it’s needed, please make sure you see the whole commands, otherwise manually scroll vertically.

    1. Create a .ssh directory in your home dir (probably exists already):
      mkdir -p $HOME/.ssh

      Make sure you allow no one else access here than yourself:

      chmod 0700 $HOME/.ssh
    2. Create the Key files (preferably avoid running this ON the actual server, since your private key shouldn’t touch your server). Use a strong password.
      ssh-keygen -t rsa -b 4096 -f my_new_keys
    3. Ship the to the server:
       ssh-copy-id -i "user@server"
    4. Now, you can see if your key works (if you use putty, google for puttygen and openssh keys to convert your private key to putty format):
      ssh user@server -i my_new_keys


Optionally, change the format of the private key you just generated to PKCS8 for stronger security.

Make sure your SSH-client can handle PKCS8. The server needs no modification since this is client side.
This will let you input your password to decrypt the key with the password you decided earlier, and encrypt it again using the pkcs8 key format.

openssl pkcs8 -topk8 -v2 des3 -in my_new_keys -passin OLDPASS -out NEWPASS

Confgure SSHD

Now it is time to change some things in your sshd config on your server.
Make sure you have the following set in /etc/sshd/sshd_conf

PasswordAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes

This will force you to only use your private key when you login to your server.

Or specify a user that can only login via ssh using key:

Match User SuperBOFH
PasswordAuthentication no

Or match a whole group:

Match Group sudoers
PasswordAuthentication no

Re-load openssh after changed has been done to the sshd_conf file:

 service ssh reload 

Now keep your private key safe! Preferably on an encrypted usb thumb drive or similar.


Migrating a Xenserver Debian-VM to Hyper V 2012

Here is a quick and dirty guide to export xen vm to hyper v 2012 so it wouldn’t escape my mind.

The surgery was conducted on XCP 1.5, but probably work similarly on other versions (but I have no clue really).


  1. Shutdown your vm and export it via xencenter. This was painfully slow. took me 3 hours for a 150Gb vm which in the end produced a 99Gb large file.
  2. Get xenconvert 2.3.1 since later versions doesn’t have the ability to convert a vm exported to file. Also note that its quite picky on OS. It ran however fine on Windows 7 but not Server 2012.  This will allow you to create a VHD out of your Xen export.


  1. Create a new machine in Hyper-v and select the VHD which you just created.
  2. Boot the vm, while in grub choose to edit the parameters and remove the console=hvc0 part. Go on and boot.
    Without this part the boot procedure will almost immediately freeze without any error message.
  3. Log in and edit /etc/default/grub and remove console=hvc0
  4. Run update-grub and reboot the machine.
  5.  Edit /etc/inittab remove the ‘co hvc0’ line and you will get rid of the annoying co messages popping up in your face all the time.
  6. Uninstall all the xenserver guest utils.
  7. Reboot.
  8. ????
  9. Profit!!

Now dance & enjoy the built in kernel modules for Intergration Services the comes with Debian!

Post-install change of Instance Collation in MS SQL 2008 r2 / 2012

Sometimes people don’t know what they want, until you start bothering them about it.

In this strictly hypothetical case, you relied on your default collation settings picked by the SQL server installer since no other hints had been given by the client.

This choice of collation was of course wrong!

Now you need to change the instance collation, which pretty much wipes all your instance settings and you have to reconfigure much of it (if not all) since it will rebuild your system databases.

You’ll need the installer available. Simply issue the following command:

setup.exe /q /ACTION=RebuildDatabase /INSTANCENAME=MSSQLSERVER /SAPWD=”r@ndomp4ss0wrd” /SQLSYSADMINACCOUNTS=BUILTIN\ADMINISTRATORS mydomain\myuser /SqlCollation=Latin1_General_CI_AI

This will also reset your DB/LOG locations on SQL Server 2008, didn’t happen for my SQL 2012 instance though.

I encountered the following error message with SQL 2012 when running above command:
“The Windows account “Art\Vandelayblabla” does not exist and cannot be provisioned as a SQL Server system administrator.”

Thats because I had encapsulated the sysadminaccounts with citation marks (“), which apparently sucks. So even if you supply multiple accounts you still can’t use “ for encapsulation, really annoying if you are used to *nix standards/common sense.
For multiple accounts just separate them with whitespace (as in my example).

Reading up