And just take a look at this,
that orange glow of a sunset coming down on another module.
Congratulations!
Give yourself a big slap on the back.
You can now secure your SSH access to your server.
We've looked at how we can authenticate our remote hosts,
and that's done normally through the known_hosts file inside of
your home directory in the .ssh subdirectory.
But we also saw how we could centralize that in the /etc/ssh
subdirectory and the file ssh_known_hosts.
We took a look at making customizations to our system,
and in our client,
we can go through and configure the .ssh subdirectory and the config file.
We looked at a couple of options.
If you remember those,
there was the StrictHostKeyChecking and the UserKnownHostsFile.
We can set the behavior of the SSH client,
and in setting, let's say, StrictHostKeyChecking to be off,
and I use a known_hosts file to be dev/null,
we can choose not to persist our keys.
Now the idea of this is then even though it's bizarre
not authenticating our servers, normally we want that,
if we are very quickly recycling IP addresses and virtual machines on a known
and safe network, such as a virtual machine host‑only network,
we can make life more convenient for ourselves by not having to
delete previously used public keys from unknown hosts.
Another way we can make life more secure and easier for ourselves is
generating public key and private key pairs for ourselves as users.
With this then, we can authenticate using our public key.
The public key needs to be copied across to our target system,
and we can do that with the ssh‑copy‑id command.
When copying across,
we are adding our public key through to a list of
keys in the authorized_keys file.
Again,
this will be in our target user home directory and
the .ssh_authorized_keys file.
It's important to know the names of these files so you know what you're
looking at when you start listing this directory.
We should always secure our private keys.
If we don't, anybody who has access to the key can use it,
but we're going to find it a pain in the neck having to add in
our passphrase every time we want to use it.
So to mitigate that, we can use the ssh‑agent,
that then can cache our passphrases,
and we can add additional keys to the agent using ssh‑add.
A final part of the story was to reduce the amount of server public
keys that we need to store within our known hosts.
If we can sign all of our server public keys,
we only need the certificate authority key to be stored in our client.
So especially if we're working in an enterprise and may be
connected to 20 or 30 different SSH hosts,
it certainly becomes a much easier way of managing the overheads of known hosts.
The ssh‑keygen utility again comes to the rescue here,
and we looked at the option ‑s,
where we could use a certificate authority to sign our
certificate requests coming in from our clients.
And that's it.
As I say, give yourself a great big cookie,
a slap on the back, but don't sit down for too long.
Oh, no,
I want you to come back and come again very soon as we go through and take a look at how we can elevate our privileges in Linux.