Understanding Azure Linux VM Authentication with SSH Key Pairs

The best and most secure option for authenticating to an Azure Linux VM is with a private & public key pair. It is possible to configure password authentication during the deployment of a VM, but this could be subject to a brute-force attack. A private & public key pair is used to secure the authentication, the Azure Linux VM has the public key and the administrator’s workstation stores the private key. It is possible to use the same key pair to authenticate to multiple Azure Linux VM instances, any most do.

I am going to start by deploying a new Ubuntu instance as an Azure VM, from the deployment I am going to select SSH Public Key for the authentication type. For certificate-based authentication you must still specify a username, in this example I have went with AzureUser. I have also selected the option to generate a new key pair as part of this deployment. This key pair will become my primary set of keys to authenticate to all my Azure Linux VM instances, so I have given it a descriptive name. 

Continue through the rest of the wizard to deploy a new Azure Virtual Machine. Once you get to send and you push the configuration to Azure Resource Manager in the form of a deployment you will be faced with this. You must select the option to download the private key as Azure does not store this for you. If you fail to download the private key at this stage this key pair will be null and void. 

The default format is PEM when you generate a key pair directly from Azure. This is what format the private key is downloaded in. If you want to authenticate to Azure Linux VMs using Putty you will have to convert the PEM file to PPK, or authentication will fail. To do this the PuttyGen tool can be used. The first step is to import the private key PEM file from Azure. 

Once successfully imported you must then use the Save Private Key option to ensure you end up with a PPK file which Putty can parse for authentication. 

Once you have a PPK version of the private key, you can use Putty to authenticate to the Azure Linux VM. Do not forget you must point to the PPK file from inside Putty under SSH > Auth.

Ok so we have covered how to deploy a new Azure Linux VM with a new key pair, convert the private key to a form in which Putty can use and authenticate to a VM.

The next step is to configure other Azure Linux VM’s to use this key pair for authentication. A new resource is created in the Azure Resource Group in which the next Azure Linux VM was deployed, this resource is an SSH Key. This is the public key side of this key pair which can be configured on other VM instances. If you query the SSH Key, we can copy and paste the key itself. 

Now if we want to update existing VMs to use the key pair we can go to the VM and under Reset Password select thee Reset SSH Public Key option. From here we paste in the new public key which was created as part of the original VM. 

Once this has been committed, we will be able to use out master private key to authenticate to this Azure Linux VM. 

Configure Azure Linux VM for Certificate Authentication

PuttyGen is handy tool which is installed as part of Putty. It allows you to generate key pairs, this first step is to click Generate. This will then use mouse inputs to generate a random key pair. Once this has completed you will see a Public Key displayed in the Key window.

In this example I am going to reconfigure an existing Azure Linux VM to use certificate-authentication instead of passwords. This VM was deployed using password authentication, which will still work post this configuration change. When key pairs are used for authentication they are placed in the following way:

·         Public Key - this is placed on the Azure Linux VM

·         Private Key - this is kept on the administrative workstation

The key pair can be used to authenticate to many Azure Linux VMs, the important factor is keeping the private key secure. The next step is to click Save Public Key, you will be prompted to enter a passphrase which is entirely optional. If a passphrase is entered here, you will be required to enter it when you authenticate to your Azure Linux VM's using this key pair. Once this has been done, we also must do the same for the private key so click Save Private Key and choose a suitable location for PuttyGen to write it. 

All going well we should be left with two files, one holding the public key and one holding the private key.

Open the public key file, this is the key we must configure the Azure Linux VM with. Copy the entire contents of the public key file. 

From the Azure Portal find the Azure Linux VM you are looking to reconfigure and go to the Reset Password option. Click on Reset SSH Public Key.

You will be presented with the following fields. You must enter a valid username on the Azure Linux VM, in my case the default AzureUser was still being used. You then must paste in the entire public key. Click Update to commit any changes.

To test the configuration open Putty and click Connection > SSH > Auth, from here we must point to the private key file so that Putty can present it when asked by the Azure Linux VM. 

Now try to connect. You will be presented with a username prompt, I entered AzureUser in my example and as you can see the connection has been authenticated successfully with the certificates. 

Understanding AD CS CRL publication periods and configure auto publish CRL to share

By default when you deploy a two-tier AD CS the default CRL publication period is 1 week. This is set on the Offline CA and the Onsite CA. 

What does this mean?

If you have the CRL publication period set to one week, a new CRL must be published and available to clients on a weekly basis of certificate revocation will fail. 

In a two-tier AD CS infrastructure there are two CRL's in created;

Offline CA CRL - this is published by the Offline CA and should be blank unless you have revoked historic Root Certificates. This CRL is only used to by the Online CA to check the validity of Root Certificate which has been issued by the Offline CA. If certificate revocation fails for the Offline CA Root Certificate, the entire AD CS will fail. This is because all certificates are signed by the top certificate in the trust chain. By default this is set to one week, which means every week an administrator will have to boot the Offline CA, publish a new CRL and then copy it to the revocation points. It is likely that your Offline CA will only issue a single certificate, to the Online CA, if this is the case there is no risk in setting the Offline CA's CRL publishing time to months, or even years. 

To do this login to the Offline CA, open Certification Authority expand the server object, right click on Revoked Certificates and select Properties. Once this is committed, a new CRL must be created which can be done if you right click Revoked Certificates and select All Tasks > Publish. 

The newly published CRL can be found at C:\Windows\System32\CertSrv\CertEnroll the CRL files should be copied to the revocation points which are usually stored in AD LDAP, HTTP or both. It's typical for a HTTP revocation point to be on the Online CA, so that it's reachable by clients. 

Online CA CRL - this is published by the Online CA and will contain any certificates that have been revoked by administrators. Revoked certificates are not listed in the CRL until a new CRL has been generated. The Online CA CRL publication period is more important than the Offline CA, this is because it's likely that certificates issued by the Online CA might actually be revoked during the course of normal business. I usually set the Online CA to have a CRL publication period of 1 month, which means a new CRL will automatically be published every month, however once published the CRL files are not automatically copied to the revocation points on disk, which are usually served over HTTP by IIS or similar. If no certificates are revoked over the period of a month, the CRL will be unchanged, however the new files must be copied into the revocation point locations or certificate revocation will fail. 

With the Online CA CRL set to 1 month I usually just build it into a monthly maintenance task that should be provided by the SysAdmin team who are managing the AD CS environment. 

A useful way to check CRL expiration times is to use pkiview.msc which gives a clear overview of the CRL's all the way up the trust chain.