Abstract

Certificate-based SSH authentication is superior to SSH keys in many ways:

• SSH certificates intrinsically possess a validity period before and after which they are invalid for providing authentication.
• SSH certificates can be embedded with SSH restrictions that limit:
  • Who can use the certificate
  • The list of available SSH features (X11Forwarding, AgentForwarding, etc)
  • Which SSH client machines can use the certificate
  • Commands that can be run via SSH

Repository

The following github repository provides the code base to setup a Certification Authority and later sign the certificates.

https://github.com/jlangenegger/ssh_certificate/

Setup

For the purposes of this explanation, let’s consider three systems:

• Certification Authority (CA)
  • System name “ca.netdef.org“
  • Will host our Certification Authority
• Host
  • System name “host.netdef.org“
  • Will function as an SSH server
• Client
  • System name "client.netdef.org"
  • Will function as an SSH client

Certificates

There are two different certificates.

• client certificate
  • This certificate is stored on the client and is provided to the host during the ssh connection establishment.
  • It is used on the host side to authenticate the clients that try to login.
• host certificate
  • This certificate is stored on the host and is provided to the client during the ssh connection establishment.
  • It is used on the client side to authenticate the host that the client tries to login.