Having created the most wonderful certificate
authority, we need to put it into use, don't we?
The idea of a certificate authority is it can then sign the public
key of our servers, and as we've already seen, our clients only
need to trust the certificate authority.
Come on, let's do some signing.
So the first step is to make sure that we grab one of our remote
keys, and we're going to be working with our AlmaLinux system. So
we can use scp to do a secure copy,
a copy over SSH. We need to specify our user account because we don't
want to be connecting as root, vagrant@, then our remote system, so
we can go through and put in the 192.168.33.11, our AlmaLinux system.
And we want to copy, so we put colon, indicating our server, and then
we add in the path through to the, or at least one of the hosts
public key.
I'm purely picking up the rsa_key because it's an easy key name to type in.
Remember, it's the public key that we want to pick up.
We can copy that across to our local system, and we're just
going to call it alma.pub. It could be called anything that
you want, it doesn't really matter.
Hit the big Enter key and we'll be ready to go. Now we're prompted for
the password because we don't have copy to the vagrant user's public
key and private key pair, but now listing,
we can see that we've got the alma.pub file locally. With that then,
we can go through and sign it with ssh‑keygen, so ‑s to say it's a
signing request, and we point through to our private key, so this is
going to be then our server_ca.
We're going to be prompted for the passphrase for this, the ‑I is the
identity name that we want to assign, this is used in logging
activities, so we're assigning the name, alma. We're going to use then
the ‑h to say that it's a host key rather than a client key, and we've
got then ‑n for the name.
We're not using DNS name, so we're accessing by IP addresses, so
I'm adding in the IP address of my system. Remember this is the
IP address of my AlmaLinux system, you can put the IP address of
your AlmaLinux system.
Next up, we have the ‑V for the validity period, and we're saying +52w.
There are other mechanisms that we could use, such as years, but this will do,
it will last 1 year, and then put in alma.pub, our filename to read in. We're
being prompted for the passphrase for our server_ca private key, so we can add
this in, and we can see then it returns the signed information. As I list
through, we can see now that we've got the alma‑cert.pub key, as well as the
alma.pub that we originally had.
Now of course, our AlmaLinux system already has a copy of its own public
key, but it doesn't have a copy of our signed public key.
So we're going to copy that across now, so scp alma‑cert.pub through
to vagrant at 192.168.33.11. A colon indicates that we're going into
our filesystem path, and as the vagrant user, we won't have access to
the etc directory, so we're using /tmp, and we're going to put a more
realistic name,
the name that we would like it to appear as on that system, so
ssh_host_rsa_key‑cert.pub. Give this the big Enter key. Again, we have to
add in the vagrant user password, but the file is now being copied, so we
can return our attention now to the AlmaLinux system and log into the
AlmaLinux system to finish off our work.
So ssh vagrant@, and then of course, our IP address
again. We can add in then the password,
we should be used to this now, and we can go through, gain
administrative privileges on AlmaLinux, and let's make sure
we move the copied file across.
So we copied it into our tmp directory, so we should be able to find it
through tab completion, and it's simple then to put the target of copying
it across through to our etc and ssh directory. The name is going to be
correct, so we can leave the name as is, but if you do recall from the
slides, we have to add in a simple configuration. So we're going to go
through and add HostCertificate, and putting then the path through to the
certificate, so /etc/ssh, and then rather than type all of that filename
out again, why don't we just copy and paste it in from the line above?
I do like easy, don't you?
So that's the line that we want to add in, and we're going to append it,
make sure we've got the double greater than through to our /etc/ssh,
and then the sshd_config, our SSH server configuration file. Now with
this done and the big Enter key hit,
the configuration file has been edited, and we just need to make sure it's
affected by restarting our SSH daemon. Now the reality is we're up and running
as far as our host certificates is concerned, so we've centralized our keys
through the signing of this certificate.
But the reality is whilst we're still on our AlmaLinux
system and talking about the SSHD, we need to do away with
password‑based authentication.
We can disable that, and we also need to make sure that
we've disabled root login to SSH. So let's just run through
and edit our configuration file.
I can just use Escape and dot to cycle through my past arguments, so it
becomes an easy way to get back to the sshd_config. Now okay,
I don't have the vim command on this system, but that's not a problem,
I'll just change it to the more simple vi, and then I can use / to
search, and I'm going to search for Password with a capital P, and we
can see the PasswordAuthenticationUncommented is set to yes. Let's go
through and change this to no.
I'm also going to search for Permit. As I go through and search for
this, we've got PermitRootLogin, and it's set to yes,
I'm going to change this to no. This is definitely something we don't want.
It might appear more convenient to be able to log in as the root user, but
it's a known user account, so it takes one of the items away for potential
hackers to guess, they know the username. So let's make sure this is
disabled, and save our changes, and of course, we'll restart the SSH
daemon. So we've secured our system now by not allowing password‑based
authentication or root login, and we've amalgamated our known hosts into
our host certificate.
So going back to my client where my client has this as a known host,
I'm going to ensure that we are utilizing the signed certificate by
going through and removing the entry,
the individual entry, I have for the 11 system.
Now ideally, I would add in signed certificates to the Ubuntu and the
openSUSE system, but for ease of this demonstration,
we're just doing it on the AlmaLinux system.
I'm quite happy to save these changes now knowing that the only way
I've got of authenticating the AlmaLinux host is through the
certificate authority, but remember, we also made some other
changes to the AlmaLinux system, and if we recall, we can test our
authentication mechanisms.
Let me just return back to the vagrant user.
If we test the authentication methods using ssh ‑o and
PreferredAuthentications, that's a terrible word to spell,
isn't it, preferred? But I think that's going to be correct.
If we set that to none and target then our 192.168.33.11 system, now
we've not been prompted to pick up a key, so that's a good sign, we
know the certificate authority is working. But, we can see then that
we don't support password‑based authentication now, so our system is
more secure.
If we want to double check though everything is working, if I use ssh ‑v
and target then my AlmaLinux system, the verbose switch is going to show me
the actions that are taking place. And if I scroll back, I can see then the
server host certificate is being used, and that's being used to
authenticate my AlmaLinux system.
So we've seen a lot in this demonstration. We've been through and we've
signed the AlmaLinux keys on our certificate authority,
we've copied them back, we've set up our host certificate in our SSHD
configuration, and we've ensured that we've only got the required
authentication mechanisms that we need. Our system is now secure.