112 lines
3.9 KiB
Markdown
112 lines
3.9 KiB
Markdown
|
+++
|
||
|
|
title = "ssh certificates part 2"
|
||
|
|
date = "2015-07-28T21:20:49+00:00"
|
||
|
|
author = "Gibheer"
|
||
|
|
draft = false
|
||
|
|
+++
|
||
|
|
|
||
|
|
This is the second part of the SSH certificate series, server side SSH
|
||
|
|
certificates. You can find the first one [here](/118).
|
||
|
|
|
||
|
|
This post shows, what use server side certificates can be and how they can be
|
||
|
|
created.
|
||
|
|
|
||
|
|
What use have server side certificates?
|
||
|
|
---------------------------------------
|
||
|
|
|
||
|
|
SSH certificates on the host side are used to extend the ssh host keys. These
|
||
|
|
can be used to better identify a running system, as multiple names can be
|
||
|
|
provided in the certificate. This avoids the message of a wrong host key in a
|
||
|
|
shared IP system, as all IPs and names can be provided.
|
||
|
|
|
||
|
|
SSH certificates can also help to identify freshly deployed systems in that the
|
||
|
|
system gets certified directly after the deployment by a _build ca_.
|
||
|
|
|
||
|
|
signing a host key
|
||
|
|
------------------
|
||
|
|
|
||
|
|
For this step, we need a CA key. How that can be generated was mentioned
|
||
|
|
in the [first part](/118).
|
||
|
|
We also need the host public key to sign. This can be either copied from /etc/ssh/ from
|
||
|
|
the server or it can be fetch using _ssh-keyscan_.
|
||
|
|
|
||
|
|
ssh-keyscan foo.example.org
|
||
|
|
|
||
|
|
It can also take a parameter for a specific type
|
||
|
|
|
||
|
|
ssh-keyscan -t ed25519 foo.example.org
|
||
|
|
|
||
|
|
This is needed for some older versions of openssh, where ed25519 public keys
|
||
|
|
were not fetched by default with _ssh-keyscan_.
|
||
|
|
|
||
|
|
The output returned looks like the following:
|
||
|
|
|
||
|
|
zero-knowledge.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPIP0JSsdP2pjtcYNcmqyPg6nLbMOjDbRf0YR/M2pu2N
|
||
|
|
|
||
|
|
The second and third field need to be put into a file, so that it can be used
|
||
|
|
to generate the certificate.
|
||
|
|
|
||
|
|
A complete command would then look like this:
|
||
|
|
|
||
|
|
ssh-keyscan foo.example.org | awk '/ssh|ecdsa/ { print $2,$3 }' > host.pub
|
||
|
|
|
||
|
|
With the resulting file, we can now proceed to create the certificate.
|
||
|
|
|
||
|
|
ssh-keygen \
|
||
|
|
-s ca.key \
|
||
|
|
-V '+52w1d' \
|
||
|
|
-I 'foohost' \
|
||
|
|
-h \
|
||
|
|
-n foo.example.org,bar.example.org \
|
||
|
|
host.pub
|
||
|
|
|
||
|
|
The meaning of the options is:
|
||
|
|
|
||
|
|
* `-s` the key to use for signing (the ca)
|
||
|
|
* `-V` interval the certificate is valid
|
||
|
|
* `-I` the identity of the certificate (a name for the certificate)
|
||
|
|
* `-h` flag to create a host certificate
|
||
|
|
* `-n` all names the host is allowed to use (This list can also contain IPs)
|
||
|
|
|
||
|
|
The last option is the public key file to certify.
|
||
|
|
|
||
|
|
This results in a file host-cert.pub, which contains the certificate. It can be
|
||
|
|
viewed like the SSH client certificate, with _ssh-keygen_.
|
||
|
|
|
||
|
|
ssh-keygen -L -f host-cert.pub
|
||
|
|
|
||
|
|
This file now has to be placed in the same directory like the public key on that
|
||
|
|
host, with the same `-cert.pub` ending.
|
||
|
|
|
||
|
|
The last step on the server is to adjust the _sshd_config_, so that it includes
|
||
|
|
the certificate. For that, add the following line for the fitting host key, for
|
||
|
|
example:
|
||
|
|
|
||
|
|
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
|
||
|
|
|
||
|
|
With a reload, it should load the certificate and make it available for
|
||
|
|
authentication.
|
||
|
|
|
||
|
|
Now the only thing left to do is to tell the client, that it should trust the
|
||
|
|
CA to identify systems. For that, the public key of the CA has to be added
|
||
|
|
to the file `~/.ssh/known_hosts` in the following format
|
||
|
|
|
||
|
|
@cert-authority * <content of ca.pub>
|
||
|
|
|
||
|
|
The _*_ marks a filter, so different CAs can be trusted depending on the domain.
|
||
|
|
|
||
|
|
With this, you are able to connect to your server only using the certificate
|
||
|
|
provided by the server. When connecting with debugging on, you should get output
|
||
|
|
like the following:
|
||
|
|
|
||
|
|
$ ssh -v foo.example.com
|
||
|
|
...
|
||
|
|
debug1: Server host key: ssh-ed25519-cert-v01@openssh.com SHA256:+JfUty0G4i3zkWdPiFzbHZS/64S7C+NbOpPAKJwjyUs
|
||
|
|
debug1: Host 'foo.example.com' is known and matches the ED25519-CERT host certificate.
|
||
|
|
debug1: Found CA key in /home/foo/.ssh/known_hosts:1
|
||
|
|
...
|
||
|
|
|
||
|
|
With the first part and now the second part done, you can already lock up your
|
||
|
|
infrastructure pretty fine. In the next part, I will show some stuff I use
|
||
|
|
to keep my infrastructure easily managable.
|