Using certificate for SSH in Azure Linux VM

If you like to use certificate to connect via SSH to your Linux machine you will probably use that technique to access all of your VMs, even those one hosted on Azure.

This operation is really simple, because Azure Portal allow you to specify the public key during VM creation and everything else is managed by VM Creation Scripts. In the same blade where you specify username and password you can opt in to use a certificate instead of a password. You should open the file with .pub extension you’ve created previously (with ssh-keygen) and paste full content in appropriate textbox.


Figure 1: Specifying ssh public key during VM Creation

As you can see from Figure 1 the portal will validate the key with a little green sign at the right of the textbox, informing you that the public key is valid. Once the VM is created you can use Putty or your favourite ssh client to access your machine with the certificate.

Thanks to Azure Portal you can choose to use an existing certificate to access your machine

If you already created your vm using standard username and password, you can easily connect to that machine and add public key to .ssh/authorized_keys file as showed in previous blog post, or you can use Azure CLI to configure SSH on an existing VM. First of all you need to convert the file generated with ssh-keygen in a format that can be understood by Azure CLI.

Unfortunately you cannot use the .pub file as you can when you are creating the machine;  Command Line Interface tool require a file with .pem extension. You can convert your file easily with openssl utility in a Linux VM.

openssl req -x509 -new -days 365 -key id_rsa_nopwd -out id_rsa_nopwd.pem

Thanks to this command, my RSA private key file, generated with ssh-keygen is converted to a pem file. Now you can use it to configure your VM from Azure CLI.

azure vm 
	--reset-ssh --ssh-key-file z:\Secure\Rsa\id_rsa_nopwd.pem 
	--user-name gianmaria 
	--password xxxxxx

You will be prompted for Resource Group and VM Name (you can specify those two parameter from command line), then the CLI will update your Virtual Machine for you.


Figure 2: Result of the reset-access command

Now you can access your VM using certificate, and if you check your .ssh/authorized_keys file, you can check that the public key was correctly added by the Azure CLI utility.


Figure 3: I can now connect to my VM using certificate

Gian Maria.

Using Certificate to connect via SSH to your Linux Machine

The world of computer is changing and is it not possible anymore to live in an isolated silo where you use only one operating system or technology, and this is the reason why, even if my last 20 years of development and work were made exclusively on Windows technologies, in this last 2 years I had many occasion to use Linux machines.

I used Linux at the very beginning, using Slackware distribution and I was the typical guy that use command line. At that time I used Windows Maker as UI but all the administration was done via console. This is the reason why, when I need a Linux VM (docker, ElasticSearch, Solr, Mongo, etc) I always install without a GUI.

I use local Hyper-V host or Azure, and usually connect to machine via SSH with standard username and password, but this is not the optimal situation because I have lots of VM. With many Vm you can use the same password for all machines, or use a password manager to keep track of all the passwords, but this is not so secure (even if all environment are test ones).

A better solution is using certificate to connect to your Linux machine via SSH.

If you constantly use Linux VM I strongly suggest you to use SSH with certificates, because it is far more secure and manageable than using Username and Password. I’m not a security expert, but I want to simply explain how I enabled Certificated based auth in SSH to get rid of all of my passwords.

First of all you should generate a certificate with ssh-keygen.

gianmaria@ubuntu:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gianmaria/.ssh/id_rsa):
Created directory '/home/gianmaria/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/gianmaria/.ssh/id_rsa.
Your public key has been saved in /home/gianmaria/.ssh/
The key fingerprint is:
22:05:82:3e:55:14:79:06:56:70:83:63:45:88:05:67 gianmaria@ubuntu
The key's randomart image is:
+--[ RSA 2048]----+
|  =OE..+. .      |
| .*+ o+ o. .     |
| . . + o    .    |
|    . +    .     |
|     o .S o      |
|      .  . .     |
|                 |
|                 |
|                 |

The only option this command is asking you is a password to encrypt the certificate, if you prefer more security please choose a strong password.

Now you have two files in your .ssh directory, one is the private key and the other is the public key. Asymmetric encryption permits you to verify a private certificate with the public key, and SSH has a file in .ssh/authorized_key of each user account where you should list all Public Keys of certificates allowed to login to that account. Now that you have a valid Public key you can add it to the list of authorized key to connect to the current account with a simple account.

gianmaria@ubuntu:~/.ssh$ cat >> authorized_keys

Each account has a list of Public Keys related to certificate that are allowed to login with that account

Now you can use the private key to connect to this machine without the need to use username and password. The client should have access to private key, so the server can validate that key agains the list of valid Public keys (.ssh/authorized_keys) to understand if it is entiled to login.

Private key is usually password protected (remember that a password is asked during generation of the certificate) and you should store private key file in a really secure place. I’ve transferred both the file to my windows machine thanks to winSCP, then store my private and public key in keepass to securely store toghether with my passwords. Then I’ve created a folder in my system that uses encryption, and copied certificate file in that folder.

Now if you use Putty, you should use puttygen.exe to convert id_rsa file (private key) in putty format, then you can use to login with putty. This excellent tutorial will guide you through all the steps.

If you choose a password during generation of the certificate, the password will be ask to you each time you connect to the server. If you can accept less security for test machines, you can generate certificate without specifying a password. If the private key certificate has no password, you can simply double click on stored session on putty and you are logged.

Remember that, if the private key is not password protected, anyone that can get the file is able to login to the machine without any problem

I strongly suggest you to never ever generate a certificate without a strong password for every production server or for any machine where you store data you are about.

Finally, thanks to mRemoteNg ability to read putty saved sessions, I can now simply double click the connection and I’m logged to my machines.


Figure 1: mRemoteNG is able to read PuTTY saved session, now you can double click the link and you are logged.

Gian Maria.

Grey screen RDP to Ubuntu server VM running on Azure

There are a lot of articles that explains how to setup a Ubuntu machine on Azure and being able to use xrdp to access it with a standard Remote Desktop session. If you try now and use Ubuntu 14 to create your virtual machine you will discover that you are able to RDP to the machine, but after inserting credential you will be prompted with a grey Screen.

This is due to a change in Ubuntu 14, you can read details in this blog post. If you want to save time you can simply choose an older Ubuntu distribution for your Azure Machine, and in few minutes you will be able to RDP to Ubuntu from Windows machines.

I’ve personally tried with Ubuntu 12.04 LTS, that is the one originally used by the post I’ve followed, and everything runs fine.


To have a better experience, I suggest you to use 16 bit when connecting to the machine, and not use big resolution or the RDP could be a little bit slow.

Gian Maria.