In order to provide a public key, each user in your system must generate one if they don’t already have one. This process is similar across all operating systems. First, you should check to make sure you don’t already have a key. By default, a user’s SSH keys are stored in that user’s /.ssh directory.
-->With a secure shell (SSH) key pair, you can create virtual machines (VMs) in Azure that use SSH keys for authentication, eliminating the need for passwords to sign in. This article shows you how to quickly generate and use an SSH public-private key file pair for Linux VMs. You can complete these steps with the Azure Cloud Shell, a macOS or Linux host, the Windows Subsystem for Linux, and other tools that support OpenSSH.
Note
VMs created using SSH keys are by default configured with passwords disabled, which greatly increases the difficulty of brute-force guessing attacks.
For more background and examples, see Detailed steps to create SSH key pairs.
For additional ways to generate and use SSH keys on a Windows computer, see How to use SSH keys with Windows on Azure.
Azure currently supports SSH protocol 2 (SSH-2) RSA public-private key pairs with a minimum length of 2048 bits. Other key formats such as ED25519 and ECDSA are not supported.
Use the ssh-keygen command to generate SSH public and private key files. By default, these files are created in the ~/.ssh directory. You can specify a different location, and an optional password (passphrase) to access the private key file. If an SSH key pair with the same name exists in the given location, those files are overwritten.
The following command creates an SSH key pair using RSA encryption and a bit length of 4096:
If you use the Azure CLI to create your VM with the az vm create command, you can optionally generate SSH public and private key files using the --generate-ssh-keys option. The key files are stored in the ~/.ssh directory unless specified otherwise with the --ssh-dest-key-path option. The --generate-ssh-keys option will not overwrite existing key files, instead returning an error. In the following command, replace VMname and RGname with your own values:
To create a Linux VM that uses SSH keys for authentication, specify your SSH public key when creating the VM using the Azure portal, Azure CLI, Azure Resource Manager templates, or other methods:
If you're not familiar with the format of an SSH public key, you can display your public key with the following cat command, replacing ~/.ssh/id_rsa.pub with the path and filename of your own public key file if needed:
A typical public key value looks like this example:
If you copy and paste the contents of the public key file to use in the Azure portal or a Resource Manager template, make sure you don't copy any trailing whitespace. To copy a public key in macOS, you can pipe the public key file to pbcopy. Similarly in Linux, you can pipe the public key file to programs such as xclip.
The public key that you place on your Linux VM in Azure is by default stored in ~/.ssh/id_rsa.pub, unless you specified a different location when you created the key pair. To use the Azure CLI 2.0 to create your VM with an existing public key, specify the value and optionally the location of this public key using the az vm create command with the --ssh-key-values option. In the following command, replace VMname, RGname, and keyFile with your own values:
If you want to use multiple SSH keys with your VM, you can enter them in a space-separated list, like this --ssh-key-values sshkey-desktop.pub sshkey-laptop.pub.
With the public key deployed on your Azure VM, and the private key on your local system, SSH into your VM using the IP address or DNS name of your VM. In the following command, replace azureuser and myvm.westus.cloudapp.azure.com with the administrator user name and the fully qualified domain name (or IP address):
If you specified a passphrase when you created your key pair, enter that passphrase when prompted during the login process. The VM is added to your ~/.ssh/known_hosts file, and you won't be asked to connect again until either the public key on your Azure VM changes or the server name is removed from ~/.ssh/known_hosts.
If the VM is using the just-in-time access policy, you need to request access before you can connect to the VM. For more information about the just-in-time policy, see Manage virtual machine access using the just in time policy.
For more information on working with SSH key pairs, see Detailed steps to create and manage SSH key pairs.
If you have difficulties with SSH connections to Azure VMs, see Troubleshoot SSH connections to an Azure Linux VM.
Step 1: Verify that you have openssl installed.
If not, install openssl using:
If you are using Microsoft(r) Windows, checkout http://gnuwin32.sourceforge.net/packages/openssl.htm for details about the openssl package on Windows.
If you using Linux, you can use the default package manager to get the openssl package installed on your box. For example:
Step 2: Create a RSA private key.
server.key is a PEM RSA private key. To know more about what is a PEM file and it’s significance, read What is a Pem file and how does it differ from other OpenSSL Generated Key File Formats? at serverfault.com.
Step 3: Create the Certificate Signing Request (CSR) utilizing the RSA private key we generated in the last step.
The ‘challenge password’ is used by the Certificate Authority (CA) to authenticate the certificate owner when they have to revoke the certificate. There is no way to revoke a Self-Signed Certificate via Certificate Revocation List (CRL) (refer: https://devcenter.heroku.com/articles/ssl-certificate-self#generate-private-key-and-certificate-signing-request]
As a result of executing the above command, you will find a file named server.csr (‘csr’ stands for Certificate Signing Request) in the same directory.
Step 4: Generate a file named, v3.ext with the below listed contents:
This step is required because when you load the certificate in the Chrome browser, it would display an error portrayed in the below screenshot.
Setting the DNS.1 value in v3.ext file to be same as the Common Name that you mentioned while generating the certificate signing request would resolve the error. Refer https://stackoverflow.com/questions/43665243/chrome-invalid-self-signed-ssl-cert-subject-alternative-name-missing for more details about the subject alternate name missing error and the solution.
The above command will use the Certificate Signing Request and the RSA Private Key that we generated as part of executing the previous steps and generate a Certificate file named, server.crt (‘crt’ is an abbreviation of ‘Certificate’) and place it in the same directory.
Step 5: Import the newly generated certificate in your Keychain (Mac OSX only).
Since this is a self-signed certificate, the browser would display a warning mentioning that the certificate is self-signed and the website should not be trusted as portrayed in the below-listed screenshot captured on the Chrome browser.
Click the Advanced hyperlink at the bottom of the warning page and click Proceed to hyperlink.
The browser will allow you to proceed and open the homepage but will mark the site as Not-Secure as portrayed in the image below.
To avoid this accepting the self-signed certificate everytime you restart chrome or restart your web server, follow the steps outlined at Google Chrome, Mac OS X and Self-Signed SSL Certificates to add the certificate to your Mac OSX Keychain. Restart Chrome.
Other platforms like Microsoft(r) Windows and Linux have similar techniques to import a certificate into a browser. A quick Google(r) search should be able to provide you with the exact steps based on the browser that you use.
Now Chrome should happily display the green ‘Secure’ icon against the URL when you navigate to your locally deployed website. Also, the Security tab within the Developer Tools should list the site as ‘Secure’ as portrayed in the screenshot below.
References: