| Table of Contents |
|---|
| Children Display | ||
|---|---|---|
|
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.