And yes, we're going to dive out through to our command line now,
where the learning really begins.
We're going to be investigating the known_hosts file.
We'll be looking at how we can use CLI options to
affect the behavior of known hosts.
We're going to also look at storing some of our options inside
of the .ssh directory and the config file,
so we can have customizations that remain in place.
Go on.
Let's find that command line.
And here we are, look at the command line of my Ubuntu system.
Now we know we've already connected to all three of my hosts from
the Ubuntu client in the previous exercise,
so that means that we are going to have inside of our .ssh directory,
inside of the known_hosts file, three public keys.
For each server that I connect to,
I have the public key stored locally inside of the known_hosts.
I have the known_hosts here.
I also have the authorized_key file.
The authorized_key file is being used by vagrant, so I can
authenticate using a public key/private key pair without
needing to add in a password.
We'll see more on our authorized_keys later.
But for the moment, we're going to be concentrating on the known_hosts.
The mechanism that we can use to authenticate the hosts that we connect to.
Now I've connected to three hosts, so I have three known_hosts.
Wc ‑l counts the number of lines.
When we look at it, though, it might appear to be more than three lines,
but that's just the line wrap that we're noticing,
the length of the keys.
It's these public keys that are used as a trust relationship.
If I go through and remove the known_hosts file,
then we have no trust relationship left.
So if I try and connect to one of my hosts,
the default behavior is that we're going to be
prompted to accept the public key.
It is similar to what we saw before.
So if I go through and say connect to my Alma Linux
system if I don't specify the username, we are connecting as vagrant,
I'm presented with the public key that is being
offered by the Alma Linux system.
I can choose to accept it or not accept it, so I can say yes.
We're now being prompted for the password,
so we've got a fully‑encrypted channel.
But we've also stored the public key locally inside of that known_hosts file,
so we've got a trust relationship that has now been established.
If I go through now and take a look at the known_hosts,
I'm inside of the .ssh directory.
We can see we've got the entry there that's coming from my Alma Linux system.
Now I can clear my screen with Ctrl+L.
And if I go back and maybe try connecting through to my SUSE syste, I can
affect the behavior of that prompt using command‑line options,
so ‑o is for our option, and then I can go through and say StrictHostKeyChecking,
and I can set it to no.
So we are still going to store the key,
but we don't care whether or not we've got the key already.
So as I go through now and connect, I'm going straight to the Password prompt.
We haven't been prompted to accept the key.
We have still stored it, though,
we're just prompting don't question me about the key.
So if I exit out of my openSUSE system and then go through and just
take a look back on my Ubuntu and known_hosts file,
I've now got the two keys, but that's not the only option we can use.
So again, I can clear my screen,
and let's go back and delete the file again removing any
trust relationship that we might have.
And I think em should be rm.
Ctrl+A, A for apple, will move you to the beginning of the line,
so quick navigation.
Now, we again have no trust relationship,
but if I go through now and put StrictHostKeyChecking=no,
add in a second ‑o for another option,
and I can specify where the UserKnownHosts file is located.
So instead of using the default known_hosts,
I can specify to store the key in /dev/null.
Essentially, I am not storing the key.
So this way, then, I have no permanent trust relationship.
Every time I connect,
I'm going to be presented with the public key of the remote system.
Let me just exit out again.
Now this might seem like a very bizarre thing to do.
Why would you just want to ignore security like this?
Well, if we're using virtual machines,
especially with a desktop operating system and making use of host‑only networks,
we might recycle our virtual machines very frequently.
The problem is, though,
each time we recycle a virtual machine using that same IP address,
it's going to be represented by a different public key,
and our connection is going to fail.
Let me show you. I can easily demonstrate it to you.
If I go back and connect through to my Alma Linux system.
We'll store the host key normally, so in our known_hosts file,
so all of that's done, but let me exit out of it.
And now I'm going to move across to my host operating system,
and I'm going to use vagrant to get rid of my virtual machine.
I've finished with it, so I'm recycling it.
So I'm using the vagrant client on my host to destroy the Alma Linux system.
That takes out the instance of the virtual machine that we've got.
I can fire up a new one straight away, so it's not too much of a problem.
And with the virtual machine destroyed,
I can now go through and use vagrant up alma,
so it's going to fire the virtual machine up again.
Once it has fired up, I can go back to my Ubuntu system.
Just so we're not affecting the behavior of anything,
I'm just going to connect without options.
And the problem that we're going to see straight away is that it's
really telling me that something is bad going on now.
The previously stored key I had now does not match
the key that is being presented, so obviously,
something bad is going on.
Well, we know it's not, so it's easy for me to delete that known_hosts record.
To be honest, I could delete the home file,
but we can see I can go through and delete with ssh‑keygen.
So it shows me on the screen, but I can go through and do an ssh‑keygen ‑R,
put in the IP address that I've connected to.
It deletes the key from the file, and I'm ready to go again.
However,
if I go through inside of my .ssh directory and create a file called config,
and if I put our Host record for 192.168.33.*,
so anything on the 192.168.33 network.
I can put in those options for the StrictHostKeyChecking,
don't ask, don't prompt me about StrictHostKeyChecking,
but this is only applying to hosts on this network,
my host‑only network.
And I can go through and specify the path of my
UserKnownHostsFile to be /dev/null.
So now I'm putting the options that are convenient for me without risking
any security because it's only accessible from my system.
Now if I go through now to the Alma Linux system,
well, of course, I can't authenticate.
I haven't set the vagrant password, we've just recycled that virtual machine.
But we can then jump out of this and check the known_hosts file,
and we'll see that the known_hosts file is empty.
It doesn't store any hosts, and that's going to continue if I
try and connect to my existing SUSE system.
If I go through from the Ubuntu system connecting through to the SUSE system,
now, of course, I can authenticate to that because the password is still valid.
But when I look at my known_hosts, because we're on that 192.168.33 network,
we're not storing any of the public keys.
So it's working in my favor.
So hopefully, we understand a little bit more about our known_hosts file,
and how using options either from the command line or through our configuration file, we can affect the behavior of known hosts.