Generate Ssh Key From Certificate

10.12.2020/ Comments off

How To Generate Ssh Key Pair
Powershell Generate Ssh Key
Generate Ssh Key From Certificate Download
Generating Private Key From Certificate
Generate Ssh Key Ubuntu

Important: This example is intended to provide general guidance to IT professionals who are experienced with SSL requirements and configuration. The procedure described in this article is just one of many available methods you can use to generate the required files. The process described here should be treated as an example and not as a recommendation.

When you configure Tableau Server to use Secure Sockets Layer (SSL) encryption, this helps ensure that access to the server is secure and that data sent between Tableau Server and Tableau Desktop is protected.

Mar 28, 2014 SSH private / public key pair & self sign certificate. One of the most common forms of cryptography today is public-key cryptography helps to communicate two system by encrypting information using the public key and information can be decrypted using private key. Enter SSH keys. These cannot be brute-forced – they are simply too complex. If you can, disable password logins in your “sshdconfig” file (on the server) and use keys instead. In case you travel and can’t carry your laptop with you, just keep your private key on a.

Looking for Tableau Server on Linux? See Example: SSL Certificate - Generate a Key and CSR.

Tableau Server uses Apache, which includes OpenSSL. You can use the OpenSSL toolkit to generate a key file and Certificate Signing Request (CSR) which can then be used to obtain a signed SSL certificate.

Steps to generate a key and CSR

To configure Tableau Server to use SSL, you must have an SSL certificate. To obtain the SSL certificate, complete the steps:

Generate a key file.
Create a Certificate Signing Request (CSR).
Send the CSR to a certificate authority (CA) to obtain an SSL certificate.
Use the key and certificate to configure Tableau Server to use SSL.

You can find additional information on the SSL FAQ page on the Apache Software Foundation website.

Configure a certificate for multiple domain names

Tableau Server allows SSL for multiple domains. To set up this environment, you need to modify the OpenSSL configuration file, openssl.conf, and configure a Subject Alternative Name (SAN) certificate on Tableau Server. See For SAN certificates: modify the OpenSSL configuration file below.

Set the OpenSSL configuration environment variable (optional)

To avoid using the -config argument with every use of openssl.exe, you can use the OPENSSL_CONF environment variable to ensure that the correct configuration file is used and all configuration changes made in subsequent procedures in this article produce expected results (for example, you must set the environment variable to add a SAN to your certificate).

Open the Command Prompt as an administrator, and run the following command:

set OPENSSL_CONF=c:Program FilesTableauTableau Serverpackagesapache.<version_code>confopenssl.cnf

Notes:

When setting the Open SSL configuration environment variable, do not enclose the file path with quotation marks.
If you are using a 32-bit version of Tableau Server on a 64-bit computer, run the set OPENSSL_CONF=c:Program Files (x86)TableauTableau Serverpackagesapache.<version_code>confopenssl.cnf command instead.

Generate a key

Generate a key file that you will use to generate a certificate signing request.

/office-2007-telephone-activation-key-generator-download.html. Open the Command Prompt as an administrator, and navigate to the Apache directory for Tableau Server. For example, run the following command:
cd C:Program FilesTableauTableau Serverpackagesapache.<version_code>bin
Run the following command to create the key file:
openssl.exe genrsa -out <yourcertname>.key 4096
Note: This command uses a 4096-bit length for the key. You should choose a bit length that is at least 2048 bits because communication encrypted with a shorter bit length is less secure. If a value is not provided, 512 bits is used.

Create a certificate signing request to send to a certificate authority

Use the key file you created in the procedure above to generate the certificate signing request (CSR). You send the CSR to a certificate authority (CA) to obtain a signed certificate.

Important: If you want to configure a SAN certificate to use SSL for multiple domains, first complete the steps in For SAN certificates: modify the OpenSSL configuration file below, and then return to here to generate a CSR.

Run the following command to create a certificate signing request (CSR) file:
openssl.exe req -new -key yourcertname.key -out yourcertname.csr
If you did not set the OpenSSL configuration environment variable, OPENSSL_CONF, you might see either of the following messages:
- An error message about the config information being unable to load. In this case, retype the command above with the following parameter: -config .confopenssl.cnf.
- A warning that the /usr/local/ssl directory cannot be found. This directory does not exist on Windows, and you can simply ignore this message. The file is created successfully.
To set an OpenSSL configuration environment variable, see Set the OpenSSL configuration environment variable (optional) section in this article.
When prompted, enter the required information.
Note: For Common Name, type the Tableau Server name. The Tableau Server name is the URL that will be used to reach the Tableau Server. For example, if you reach Tableau Server by typing tableau.example.com in the address bar of your browser, then tableau.example.com is the common name. If the common name does not resolve to the server name, errors will occur when a browser or Tableau Desktop tries to connect to Tableau Server.

Send the CSR to a certificate authority to obtain an SSL certificate

Send the CSR to a commercial certificate authority (CA) to request the digital certificate. For information, see the Wikipedia article Certificate authority and any related articles that help you decide which CA to use.

Use the key and certificate to configure Tableau Server

When you have both the key and the certificate from the CA, you can configure Tableau Server to use SSL. For the steps, see Configure External SSL.

For SAN certificates: modify the OpenSSL configuration file

In a standard installation of OpenSSL, some features are not enabled by default. To use SSL with multiple domain names, before you generate the CSR, complete these steps to modify the openssl.cnf file.

Open Windows Explorer and browse to the Apache conf folder for Tableau Server.
For example: C:Program FilesTableauTableau Server<version_code>apacheconf
Open openssl.cnf in a text editor, and find the following line: req_extensions = v3_req
This line might be commented out with a hash sign (#) at the beginning of the line.
If the line is commented out, uncomment it by removing the # and space characters from the beginning of the line.
Move to the [ v3_req ] section of the file. The first few lines contain the following text:
# Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment
After the keyUsage line, insert the following line:
subjectAltName = @alt_names
If you’re creating a self-signed SAN certificate, do the following to give the certificate permission to sign the certificate:
1. Add the cRLSign and keyCertSign to the keyUsage line so it looks like the following: keyUsage = nonRepudiation, digitalSignature, keyEncipherment, cRLSign, keyCertSign
2. After the keyUsage line, add the following line: subjectAltName = @alt_names
In the [alt_names] section, provide the domain names you want to use with SSL.
DNS.1 = [domain1] DNS.2 = [domain2] DNS.3 = [etc]
The following image shows the results highlighted, with placeholder text that you would replace with your domain names.
Save and close the file.
Complete the steps in Create a certificate signing request to send to a certificate authority section, above.

Additional information

If you prefer to use a different version of OpenSSL, you can download it from Open SSL for Windows.

Thanks for your feedback!There was an error submitting your feedback. Try again or send us a message.

How To Route Web Traffic Securely Without a VPN Using a SOCKS Tunnel Tutorial

How To Set Up Multi-Factor Authentication for SSH on Ubuntu 14.04 Tutorial

Status: Deprecated

This article covers a version of Ubuntu that is no longer supported. If you are currently operate a server running Ubuntu 12.04, we highly recommend upgrading or migrating to a supported version of Ubuntu:

Upgrade to Ubuntu 14.04.

Reason:Ubuntu 12.04 reached end of life (EOL) on April 28, 2017 and no longer receives security patches or updates. This guide is no longer maintained.

See Instead:
This guide might still be useful as a reference, but may not work on other Ubuntu releases. If available, we strongly recommend using a guide written for the version of Ubuntu you are using. You can use the search functionality at the top of the page to find a more recent version.

Introduction

When configuring a large amount of servers that have many users, keeping SSH access in line for your infrastructure can get complicated. There are quite a few ways of implementing a centralized authentication authority, such as LDAP, but these are sometimes overkill.

SSH actually has the functionality to use a certificate authority to authenticate servers and clients. This works both ways. Using this system, you can authenticate a host to a client, avoiding confusing messages about being unable to validate the authenticity of the host. You can also validate the client to the host, allowing you to register a new SSH key in one place and allow access across your organization.

We’ll discuss how to leverage these certificates in both of the ways discussed above. We’ll be demoing this on three Ubuntu 12.04 VPS instances. One will serve as the host, another as the client, and the third will function as the certificate authority.

How To Configure Host Certificates

We will start by configuring certificates that will authenticate our servers to our clients. This will allow our clients to connect to our servers without needing to question the authenticity of the server.

We begin on the machine that we will be using as the certificate authority. In this example, we’ll refer to this as “auth.example.com”.

Generating Signing Keys

How To Generate Ssh Key Pair

First, we need to generate some RSA keys that will function as the signing keys. Use any user you’d like, but the root user is probably a good idea. We will be creating keys called “server_ca” and “server_ca.pub” since these will be used to authenticate our servers.

Let’s create these keys in our home directory:

You will be asked if you’d like to create a passphrase. This will add an additional layer of protection to your key in the event that it falls into the wrong hands. Once this is finished, you’ll have a private and public key in your home directory:

Signing Host Keys

Now that we have our keys, we can begin signing our host keys.

We should start by signing the host key of the certificate authority itself. We can do this using the following syntax:

Let’s go over what all of this means.

-s: This is the private key that we just created that we will use to sign all of the other keys.
-I: This is a name that is used to identify the certificate. It is used for logging purposes when the certificate is used for authentication.
-h: This marks the resulting certificate as a host key, as opposed to a client key.
-n: This is used to identify the name (user or host) that is associated with this certificate.
-V: This specifies how long the certificate is valid for. In this instance, we specify that the certificate will expire in one year (52 weeks).

Afterwards we specify the key that we want to sign.

In our case, to sign our own host RSA key, we will use a line that looks like this. We are going to identify this server as “host_auth_server”. We will be prompted for the passphrase we used when creating the signing key:

As you can see from the output, our certificate is valid for one year. It has been created in the same directory as our server host key (/etc/ssh/) and is called “ssh_host_rsa_key-cert.pub”.

Now that we have signed our host key on the certificate authority itself, we can sign the host key for the separate SSH server we’re trying to authenticate to clients.

Copy the host key from our SSH server. We’ll refer to this machine as “sshserver.example.com”. You can do this using scp:

Now, we can create a certificate from this file using the same method we used above. We’ll need to change some values to refer to the new host we’re signing:

Now, we need to copy the generated certificate file back onto the host. Again, we can use scp for this:

Afterwards, we can delete both the SSH server’s public key and certificate from our authentication server:

We now have the signed certificates in place, we just need to configure our components to use them.

Configuring Components to Use Host Certs

First, we need to continue with both of our servers (auth.example.com and sshserver.example.com) to make them aware of the certificate files we created.

On both of these machines, we’ll have to edit the main SSH daemon configuration file. Make sure you are editing the sshd_config file, not the ssh_config file:

If you can find a HostCertificate line, modify it. Otherwise, add this to the bottom of the file. We need to establish to path to our host certificate file:

Save and close the file when you are finished.

Now, restart the SSH daemon to make these changes happen:

Do this on all of the servers you are configuring host certificates for.

Now, our servers are configured to use the certificate, but our client does not know how to check the certificate that the server will present.

On our client machine, which we’ll be referring to as “client.example.com”, open or create the “~/.ssh/known_hosts” file:

We need to remove any entries that have to do with the servers we’re configuring for certificate entry. It may be best to delete everything.

Afterwards, we need to add a special entry that specifies the public key that we should use to check the certificate that our hosts will give us during login. Start it off with @cert-authority. Afterwards, it can include a domain restriction where the key will be applied, followed by the public certificate authority key that we’ve been signing everything with.

On your certificate authority machine, you can get the public certificate signing key by typing:

Using this information, the line in your ~/.ssh/known_hosts file should look like:

Save and close the file when you’re done.

Now, when you visit the SSH server for the first time from your client (using the full hostname), you should not be asked whether you trust the remote host. This is because the host has presented its host certificate to you, signed by the certificate authority. You’ve checked your known_hosts file and verified that the certificate is legitimate.

How To Configure User Keys

Now that we’ve learned how to authenticate servers to our users, we can also configure our certificate authority to authenticate our users to our servers.

As before, this process will start on our certificate authority server. We will need to generate a new set of keys, this time, to sign user certificates:

Again, select a passphrase so that your key will be protected if someone gains access.

Configuring Servers to Accept Logins with the User Certification

When you are done, you will need to copy the public key onto each of your SSH servers that need to validate user authenticity. We will do this using scp as usual:

We need to modify our SSH daemon configuration on our SSH server to look for this key.

On our “sshserver.example.com” host, open the configuration file:

At the bottom, below our HostCertificate line, we need to add another line that references the file we just copied over:

Again, we’ll need to restart the SSH daemon for these changes to take place:

Signing User Login Keys

Now that the servers are configured to trust keys signed by the users_ca key, we need to actually sign the users’ authentication keys so that this scheme will work.

First, we need to get our client key onto the certificate authority server with scp. From the cert server, type:

Now that we have the key on the cert machine, we can sign it using our users_ca key. This will be very similar to last time we signed keys using the server_ca keys, only now, we don’t include the -h parameter, because these are user keys.

The command we want is something like this. Change the “username” value to reflect the name of the user you’re signing for easier management:

Powershell Generate Ssh Key

You will be prompted for the users_ca passphrase that set during the key’s creation. Now, we have an id_rsa-cert.pub file in our directory that we need to transfer back onto our client machine:

Now, when you log into sshserver.example.com from your client computer, you should not be asked for your authentication details, even if you’ve never before logged into this server as this user.