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. Generate a 2048 bit RSA Key. You can generate a public and private RSA key pair like this: openssl genrsa -des3 -out private.pem 2048. That generates a 2048-bit RSA key pair, encrypts them with a password you provide and writes them to a file. You need to next extract the public key file. There are many reasons you might want to create a key pair on Linux, more specifically on Ubuntu. For more information about key pairs, see this. If your server is an Amazon EC2 Server Instance, you might want to look at more specific information here. Key pairs are just one way to log into a system. Jul 29, 2019  Step 1- Generate the SSH Key Pair. On your client system – the one you’re using to connect to the server – you need to create a pair of key codes. To generate a pair of SSH key codes, enter the commands: This will create a hidden directory to store your SSH keys. If you don't already have an SSH key, you must generate a new SSH key.If you're unsure whether you already have an SSH key, check for existing keys. If you don't want to reenter your passphrase every time you use your SSH key, you can add your key to the SSH agent, which manages your SSH keys and remembers your passphrase. Apr 27, 2018  (04) SSH Key-Pair Authentication (05) SFTP only + Chroot (06) Use SSHPass (07) Use SSH-Agent. Create your server's self signed SSL Certificates. If you use your server as a business, it had better buy and use Formal Certificates. Openssl rsa -in server.key -out server.key. Enter pass phrase for server.key: # passphrase.

1. Ubuntu Openssl Generate Key Pair Key
2. Ubuntu Openssl Generate Rsa Key

There are numerous articles I’ve written where a certificate is a prerequisite for deploying a piece of infrastructure.

This article will guide you through creating a trusted CA (Certificate Authority), and then using that to sign a server certificate that supports SAN (Subject Alternative Name).

Operationally, having your own trusted CA is advantageous over a self-signed certificate because once you install the CA certificate on a set of corporate/development machines, all the server certificates you issue from that CA will be trusted. If you manage a larger sized internal environment where hosts, services, and containers are in constant flux, this is an operational win.

CA trust also had advantages to self-signed certs because browsers like Chrome 58 and Firefox 48 have limitations on trusting self-signed certificates. The Windows version of Chrome is the only flavor that allows self-signed certs to be imported as a trusted root authority, all other OS do not trust the self-signed certificate. And Firefox allows you to add a permanent exception, but needs a trusted CA in order to show a fully green trust lock icon.

If you just want a self-signed SAN certificate with no backing CA, then read my article here instead, but note that it has limitations that are overcome by using a trusted CA.

Overview

If you are familiar with commercial certificates, you know that a certificate does not live in isolation. It it just the beginning of a chain of trust, where the root certificate is ultimately trusted because it sits on your local system.

We can create a SAN certificate with the same features, issued and signed by a Certificate Authority that we create. This has several benefits:

1. Better emulation of production – production certs also consist of a chain
2. Ease of administration – once a user trusts our CA, then any other SAN certificate we generate will also be trusted
3. Better browser support – not all browsers allow self-signed certs to be added into the trusted root authorities list

In this article, first we will create our own CA (Certificate Authority). Then we will use that CA to create a SAN server certificate that covers “mydomain.com” as well as any of its subdomains, “*.mydomain.com”.

If you want to test the certs we generate here, I would recommend using HAProxy. Here is a page where I describe how to do a quick HAProxy install.

Prerequisite

As a prerequisite, ensure the SSL packages are installed:

Customized openssl.cnf

The first step is to grab the openssl.cnf template available on your system. On Ubuntu this can be found at “/usr/lib/ssl/openssl.cnf”. You may find this in “/System/Library/OpenSSL/” on MacOS, and “/etc/pki/tls” on Redhat variants.

“$prefix.cnf” needs be modified with the specific information about the cert we are going to generate.

Under the [ v3_ca ] section, add the following values. For the CA, this signifies we are creating a CA that will be used for key signing.

Then under the “[ v3_req ]” section, set the following along with all the valid alternative names for this certificate.

Also uncomment the following line under the “[ req ]” section so that certificate requests are created with v3 extensions.

When we generate each type of key, we specify which extension section we want to use, which is why we can share $prefix.cnf for creating both the CA as well as the SAN certificate.

Create CA certificate

Now we will start using OpenSSL to create the necessary keys and certificates. First generate the private/public RSA key pair:

This encodes the key file using an passphrase based on AES256. Then we need to create the self-signed root CA certificate.

You can verify this root CA certificate using: /teamviewer-13-licence-key-generator.html.

This will show the root CA certificate, and the ‘Issuer’ and ‘Subject’ will be the same since this is self-signed. This is flagged as “CA:TRUE” meaning it will be recognized as a root CA certificate; meaning browsers and OS will allow it to be imported into their trusted root certificate store.

Create Server certificate signed by CA

With the root CA now created, we switch over to the server certificate. First generate the private/public RSA key pair:

We didn’t put a passphrase on this key simply because the CA is more valuable target and we can always regenerate the server cert, but feel free to take this extra precaution.

Then create the server cert signing request:

Then generate the server certificate using the: server signing request, the CA signing key, and CA cert.

The “$prefix.key.pem” is the server private key and “$prefix.crt” is the server certificate. Verify the certificate:

This will show the certificate, and the ‘Issuer’ will be the CA name, while the Subject is the prefix. Generate strong name key for dll. This is not set to be a CA, and the ‘Subject Alternative Name’ field contains the URLs that will be considered valid by browsers.

Server deployment

Servers like HAProxy want the full chain of certs along with private key (server certificate+CA cert+server private key). While Windows IIS wants a .pfx file. Here is how you would generate those files.

Browser Evaluation

When you first point Chrome or Firefox at the site with your SAN cert with CA signing, it will throw the same type of exceptions as a self-signed SAN cert. This is because the root CA cert is not known as a trusted source for signed certificates.

In Chrome settings (chrome://settings), search for “certificates” and click on “Manage Certificates”. On Windows this will open the Windows certificate manager and you should import the “ca.pem” file at the “Trusted Root Certification Authorities” tab. This is equivalent to adding it through mmc.exe, in the “local user” trusted root store (not the computer level). On Linux, Chrome manages its own certificate store and again you should import “ca.pem” into the “Authorities” tab. This should now make the security icon turn green.

In Firefox Options (about:preferences), search for “certificates” and click “View Certificates”. Go to the “Authorities” tab and import “ca.pem”. Check the box to have it trust websites, and now the lock icon should turn green when you visit the page.

Although there is a little friction doing this import, it is a one-time cost because any other certificates that you sign with this CA are now trusted. So if a cert expires and you have to replace it, or you need to change the URLs in a SAN and refresh it, none of the browsers will have an issue with trust.

REFERENCES

https://gist.github.com/jhamrick/ac0404839b5c7dab24b5 (script for CA and SAN)

https://github.com/stanzgy/wiki/blob/master/network/openssl-self-signed-certs-cheatsheet.md (exact commands for CA, intermediate, chain, server cert, validating cert+key)

https://gist.github.com/bitoiu/9e19962b991a71165268 (original source of quick SAN with no intermediate)

https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html (multiple pages of detailed lead through for CA, intermediate, and cert)

https://security.stackexchange.com/questions/38782/ssl-tls-distinction-between-self-signed-cert-and-self-signed-ca-and-other-que (discussion on CA vs Self signed)

https://stackoverflow.com/questions/5244129/use-rsa-private-key-to-generate-public-key (discussion on RSA public/private pair and info inside)

https://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-subject-alternative-names-san-work-together (explains how RFC 6125 from 2011 says SAN checked first)

https://github.com/webpack/webpack-dev-server/issues/854 (self signed cert no longer valid chrome 58)

https://bugs.chromium.org/p/chromium/issues/detail?id=700595&desc=2 (chrome 58 needs SAN for self-certs)

https://gist.github.com/akailash/7ec96e39d6951dd2293308e1d8055307 (wildcard SAN with CA, also shows how to add as trusted cert at linux level)

https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors (temporary workaround for chrome 58)

http://users.skynet.be/pascalbotte/art/server-cert.htm (use Jetty jar to transform pkcs12 to jks java keystore)

NOTES

On Ubuntu, trusted root certificates sit in the directory “/etc/ssl/certs”, and can be updated using “sudo update-ca-certificates”. On Windows it is managed through the MMC Certificate Snap-In.

If you don’t want to manually type the password, you can use passin/passout:

Now use that CA to create the root CA certificate.

-->

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.

Ubuntu Openssl Generate Key Pair Key

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.

Supported SSH key formats

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.

Create an SSH key pair

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:

Provide an SSH public key when deploying a VM

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.

Ubuntu Openssl Generate Rsa Key

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.

SSH into your VM

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.

Next steps

• purchase microsoft powerpoint for mac 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.