You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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
  • Client

Certificates

There are two different certificates that are possible:

  • 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.
    • This certificate replaces public key or password based 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.
    • This certificate replaces the authorized key file entry for a given host.

At the moment we only use the client certificate within NetDEF.

Configuration

There are separate pages the guide you through the installation process for the Certificate Authority, the client and the host:




  • No labels