We also have other options available to us.
We can centralize our known hosts.
Rather than allowing our users to make the decisions about whether
to accept the public key from the server or not,
we can have it stored centrally inside of the /etc/ssh directory,
and the file would be called ssh_known_hosts.
To collect the keys, we can make use of the command, ssh‑keyscan.
This is what we're going to take a look at just now.
So if you're ready, we're going to begin and begin with your learning.
So here we are back on my SSH client.
I'm just going to remove that configuration file so that we know we're
back to our standard behavior of storing our public keys of service that
we connect to inside of our known host file.
And just for double measure,
we'll make sure that we don't have our local known_hosts file.
So we are back at a very vanilla situation,
but rather than waiting for us to connect via SSH to be presented with the key,
we can do it in our own time,
and here where we go through and scan the AlmaLinux system,
we can see the keys that it is presenting,
and generally, it's a range of keys so the client can choose the most suitable.
We can choose what we feel is the most suitable during the key scan.
If I use the ‑t for type,
I can specify that I want to use the elliptical curve dsa key,
one of our stronger, more modern algorithms,
and as I then go through and take a look at it,
we're being presented just with that one ecdsa key.
Now the reason to do this is because I can then go
through and store this ahead of time, either in my local known host file,
but as an administrator, I can write through to the central known host file.
If I pipe the output to sudo and tee,
tee will write to the screen and the file that I specify.
I'm using the option ‑a so we append.
To be honest, though, the file won't exist to begin with,
but it's always the safest mechanism to use ‑a for append,
and we're going to write through to the /etc and /ssh directory,
and ssh_known_hosts.
Now I say, we are writing to the screen, but also the file.
Making sure that we are appending,
we can go through then and add in the IP address for
the SUSE system and then re‑run it,
putting in our good friend from the Ubuntu system.
So we've got the three keys stored, but they're not stored locally now.
When I list my .ssh directory, I don't have a known_hosts file.
But I am not going to need to have to accept any of these keys
because it's been done by the administrator.
We can demonstrate this as I go through now,
and let's connect into the open SUSE system.
You see, I wasn't prompted to collect the public key,
the trust relationship is there.
I can add in the password, and I should be authenticated through to that system,
but I say, I can leave the management of the keys to the administrator.
We also then only need to store the keys once per server.
Listing my current .ssh directory, you can see,
even having authenticated having made the connection,
we still don't have the key locally.
Why not?
Because it's stored centrally inside of /etc and /ssh,
ssh_, and then our known_hosts file.
And here we are, those same three keys that we originally have,
but now stored centrally on our server.
And I say,
the whole idea then of storing centrally is that it becomes
much more secure in collecting the keys.
We can choose when to collect the keys, or even move them via a removable drive,
so we know we're not risking network connectivity,
and we're only storing them once.
If I've got 20 clients on this system, rather than storing the key 20 times, we might as well store them once inside of this central directory.