Create SSH keys on Linux and Mac for Linux VMs in Azure
With an SSH keypair you can create Virtual Machines on Azure that default to using SSH keys for authentication, eliminating the need for passwords to log in. Passwords can be guessed and open your VMs up to relentless brute force attempts to guess your password. VMs created with Azure Templates or the
azure-cli can include your SSH public key as part of the deployment, removing a post deployment configuration. If you are connecting to a Linux VM from Windows, see this document.
In the following command examples, replace the values between < and > with the values from your own environment.
ssh-keygen -t rsa -b 2048 -C "<firstname.lastname@example.org>"
Enter the name of the file that is saved into the
Enter passphrase for azure_fedora_id_rsa:
<correct horse battery staple>
Add the newly created key to
ssh-agent on Linux and Mac (also added to OSX Keychain):
eval "$(ssh-agent -s)" ssh-add ~/.ssh/azure_fedora_id_rsa
Copy the SSH public key to your Linux Server:
ssh-copy-id -i ~/.ssh/azure_fedora_id_rsa.pub <email@example.com>
Test the login using keys instead of a password:
ssh -o PreferredAuthentications=publickey -o PubkeyAuthentication=yes -i ~/.ssh/azure_fedora_id_rsa <firstname.lastname@example.org> Last login: Tue April 12 07:07:09 2016 from 220.127.116.11 $
Using SSH public and private keys is the easiest way to log in to your Linux servers. Public-key cryptography provides a much more secure way to log in to your Linux or BSD VM in Azure than passwords, which can be brute-forced far more easily. Your public key can be shared with anyone; but only you (or your local security infrastructure) possess your private key. The SSH private key should have a very secure password (source:xkcd.com) to safeguard it. This password is just to access the private SSH key and is not the user account password. When you add a password to your SSH key, it encrypts the private key so that the private key is useless without the password to unlock it. If an attacker stole your private key and that key did not have a password, they would be able to use that private key to log in to any servers that have the corresponding public key. If a private key is password protected it cannot be used by that attacker, providing an additional layer of security for your infrastructure on Azure.
This article creates ssh-rsa formatted key files, which are recommended for deployments on the Resource Manager. ssh-rsa keys are required on the portal for both Classic and Resource Manager deployments.
Azure requires at least 2048-bit, ssh-rsa format public and private keys. To create the keys use
ssh-keygen, which asks a series of questions and then writes a private key and a matching public key. When an Azure VM is created, the public key is copied to
~/.ssh/authorized_keys. SSH keys in
~/.ssh/authorized_keys are used to challenge the client to match the corresponding private key on an SSH login connection.
This command creates a password secured (encrypted) SSH Keypair using 2048-bit RSA and it is commented to easily identify it.
ssh-keygen -t rsa -b 2048 -C "ahmet@fedoraVMAzure"
ssh-keygen = the program used to create the keys
-t rsa = type of key to create which is the RSA format
-b 2048 = bits of the key
-C "ahmet@fedoraVMAzure" = a comment appended to the end of the public key file to easily identify it. Normally an email is used as the comment but you can use whatever works best for your infrastructure.
If you are using the classic deploy model (Azure Classic Portal or the Azure Service Management CLI
asm), you might need to use PEM formatted SSH keys to access your Linux VMs. Here is how to create a PEM key from an existing SSH Public key and an existing x509 certificate.
To create a PEM formatted key from an existing SSH public key:
ssh-keygen -f id_rsa.pub -m 'PEM' -e > id_rsa.pem
Each step explained in detail. Start by running
ssh-keygen -t rsa -b 2048 -C "ahmet@fedoraVMAzure" Generating public/private rsa key pair. Enter file in which to save the key (/home/ahmet/.ssh/id_rsa): azure_fedora_id_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in azure_fedora_id_rsa. Your public key has been saved in azure_fedora_id_rsa.pub. The key fingerprint is: 14:a3:cb:3e:78:ad:25:cc:55:e9:0c:08:e5:d1:a9:08 ahmet@fedoraVMAzure The key's randomart image is: +--[ RSA 2048]----+ | o o. . | | E. = .o | | ..o... | | . o.... | | o S = | | . + O | | + = = | | o + | | . | +-----------------+
Saved key files:
Enter file in which to save the key (/home/ahmet/.ssh/id_rsa): azure_fedora_id_rsa
The key pair name for this article. Having a key pair named id_rsa is the default and some tools might expect the id_rsa private key file name so having one is a good idea. The directory
~/.ssh/ is the default location for SSH key pairs and the SSH config file.
ahmet@fedora$ ls -al ~/.ssh -rw------- 1 ahmet staff 1675 Aug 25 18:04 azure_fedora_id_rsa -rw-r--r-- 1 ahmet staff 410 Aug 25 18:04 azure_fedora_id_rsa.pub
A listing of the
ssh-keygen creates the
~/.ssh directory if it is not present and also sets the correct ownership and file modes.
Enter passphrase (empty for no passphrase):
ssh-keygen refers to a password as "a passphrase." It is strongly recommended to add a password to your key pairs. Without a password protecting the key pair, anyone with the private key file can use it to log in to any server that has the corresponding public key. Adding a password offers more protection in case someone is able to gain access to your private key file, given you time to change the keys used to authenticate you.
To avoid typing your private key file password with every SSH login, you can use
ssh-agent to cache your private key file password. If you are using a Mac, the OSX Keychain securely stores the private key passwords when you invoke
First verify that
ssh-agent is running
eval "$(ssh-agent -s)"
Now add the private key to
ssh-agent using the command
The private key password is now stored in
It is a recommended best practice to create and configure an
~/.ssh/config file to speed up log ins and for optimizing your SSH client behavior.
The following example shows a standard configuration.
# Azure Keys Host fedora22 Hostname 18.104.22.168 User ahmet # ./Azure Keys # Default Settings Host * PubkeyAuthentication=yes IdentitiesOnly=yes ServerAliveInterval=60 ServerAliveCountMax=30 ControlMaster auto ControlPath ~/.ssh/SSHConnections/ssh-%r@%h:%p ControlPersist 4h IdentityFile ~/.ssh/id_rsa
This SSH config gives you sections for each server to enable each to have its own dedicated key pair. The default settings (
Host *) are for any hosts that do not match any of the specific hosts higher up in the config file.
Host = the name of the host being called on the terminal.
ssh fedora22 tells
SSH to use the values in the settings block labeled
Host fedora22 NOTE: This can be any label that is logical for your usage and does not represent the actual hostname of any server.
Hostname 22.214.171.124 = the IP address or DNS name for the server being accessed.
User git = the remote user account to use.
PubKeyAuthentication yes = tells SSH you want to use an SSH key to log in.
IdentityFile /home/ahmet/.ssh/id_id_rsa = the SSH private key and corresponding public key to use for authentication.
Now that you have an SSH key pair and a configured SSH config file, you are able to log in to your Linux VM quickly and securely. The first time you log in to a server using an SSH key the command prompts you for the passphrase for that key file.
ssh fedora22 is executed SSH first locates and loads any settings from the
Host fedora22 block, and then loads all the remaining settings from the last block,
Next up is to create Azure Linux VMs using the new SSH public key. Azure VMs that are created with an SSH public key as the login are better secured than VMs created with the default login method, passwords. Azure VMs created using SSH keys are by default configured with passwords disabled, avoiding brute-forced guessing attempts.