SSH Certificates

SSH certificates are overcoming the challenges of traditional keys by simplifying the governance of such credentials (e.g., the issue of key sprawl is solved), improving the security and policy enforcement (digitally signed identity information and restrictions). They can be issued with an expiration date, and Linux systems support them out of the box.

This feature is available for all customers and is intended for use in production environments.

The feature is designed to provide higher levels of automation for system administrators, better visibility for InfoSec teams, which will result in faster and more successful audits.

SSH certificates are a technology that is, in many ways, superior to traditional SSH keysets of private and public keys. They provide a powerful tool in your arsenal for protecting your machine identities. One of the limitations with traditional keysets is they don't have an expiration date, so to deactivate them, you need to remove them from the server, or you need to rotate the keysets to prevent unintended access. SSH Certificates, however, support a built-in expiration date.

In addition, once you add the public key of you SSH certificate authority to the server. After that, all certificates issued by that CA that match the machine requirements will grant users access to that device. This means you don't need to add and remove each user to each unique device.

On high-level:

• SSH Protect acts as an SSH certificate authority (CA) allowing organizations to enroll certificates for authentication between their SSH clients and servers. For more information see Venafi SSH Protect as an SSH Certificate Authority.

• InfoSec teams can define multiple SSH certificate issuance templates, allowing different configurations to deal with multiple use cases. Issuance restrictions ensure compliance with you organization’s security policies. For more information see Working with issuance templates.

• We recommend that SSH CA keys be generated by and stored on a hardware security module (HSM). For more information, see Managing applications using HSM-protected keys and Venafi Advanced Key Protect.

• DevOps reams and system administrators can use native integrations (e.g., Red Hat Ansible, HashiCorp Terraform) or Venafi vCert command line utility to simplify the process of trusting the SSH CA on the corporate devices and to request SSH certificates for them.

Once you have SSH certificate issuance templates, you use the Web SDK to enroll and manage SSH certificates.

• SSH Certificate Enrollment
  If you want to request SSH certificates for your devices, but native integration is not yet available you can use SSHCertificates/Request and SSHCertificates/Retrieve API methods.
  

• SSH CA public key retrieval
  If you want to configure your devices to trust your SSH CAs you need to retrieve their CA public keys from SSH Protect. You can use SSHCertificates/Template/Retrieve/PublicKeyData API method to retrieve them and then configure your devices. For more information see Configuring your OpenSSH servers to trust your SSH CA hosted by SSH Protect.

This section introduces you to the concept of SSH certificates, and details the support that Venafi SSH Protect provides for SSH certificates.

Throughout this section, we'll use the term SSH certificates (or, sometimes, just certificates). In the industry, these can also be referred to as OpenSSH Certificates, as well as Signed Certificates.