Now the more we can remove passwords from our security equation,
the more tight our systems are going to become and the more secure they will be.
It also becomes more convenient, so it's a double benefit.
We won't have to add in annoying passwords when we're trying to connect.
As an ordinary user,
I can generate my own public key and private key
pair using the ssh‑keygen utility.
I can copy the public key using ssh‑copy‑id.
Again, if I don't specify the target user account,
it will be the same user account as my account on the local system.
Once I've copied it across, I'm going to be able to then ssh,
and I won't need to add in a password.
However, if you've used a passphrase on your private key,
you'll be prompted for that passphrase.
To avoid adding in the passphrase and keeping the private key secure,
then we can go through and use the ssh‑agent to cache our passphrase.
Come on, we need to see this, don't we?
So why don't we move out and take a look at client authentication,
looking at the keygen utility, the copy‑id , and our ssh‑agent.
And here we are again on the glorious command line of my vagrant system.
We want to be able to tighten our security by
removing the needs of our passwords.
Now when I go through and take a look inside of my .ssh directory,
I don't have a public key and private key pair.
I do have the authorized_keys file,
and this is kind of what we're going to be looking at.
But as there's an authorized key file,
it shows that you are targeted for authentication and
not a client for authentication.
And that authorized_keys file is for use of the external vagrant system.
So I'm going to create myself my own key pair,
and I do that with the utility ssh‑keygen.
If I don't use the option ‑t for type, it will generate an RSA key pair,
and I'm quite happy with that.
I could also use the option ‑b to increase the security
by specifying a higher bit count.
So I hit Enter.
I can accept the default path.
I don't need to add in a passphrase, but I should add in a passphrase.
The passphrase secures your private key, so only those people
that know the passphrase are able to use it.
So I'm putting in a passphrase, and, of course,
we have to add that twice,
but now we've generated both the public key and the private key pair.
Looking back inside of our .ssh directory, we can see the id_rsa,
the private key, and the same file with a .pub extension being the public key.
And remember, we have secured the private key with a passphrase.
It's up to us now to copy this to where we want to authenticate. And
we copy the public key using ssh‑copy‑id and targeting our hosts, so
here we're going to the AlmaLinux system.
Remember, these are my IP addresses. They could be different on your
own system. Now, of course, to be able to copy it up,
we have to have an authentication mechanism available to us, which is
password based at the moment. But now I've copied the key,
I will no longer be required to add in the password. So as I go back in, it's
not the password, it is the passphrase, but please bear with me on this.
Entering our passphrase gives us the ability to use our private key, allowing
us then to authenticate using the public key.
Having done so, I'm on the AlmaLinux 8 system, if I look inside the .ssh
directory in the home directory and the authorized_keys file,
the second entry we can see is coming from the vagrant user at the
ubuntu host, and this is the public key that we've just added in,
and this is what we use to authenticate.
Now let me exit out of my AlmaLinux system and see if we can
come to a resolution over this passphrase.
If we use the ssh‑agent, we're able to cache our passphrase. We just need
to let Bash know where the agent is running, and we do that with the eval
command reading the output of ssh‑agent. And that then tells Bash the
process ID of where the agent is running.
Now that Bash knows where the agent is running, we can
start adding in our keys to the agent.
If we're using the default RSA key, we can just use ssh‑add,
and we don't need to specify a key name.
If we're using other keys, we would have to add in the key name. At this
stage, I've got to open my private key, but that's okay.
I only need to open it once. Now that it's open, I can go
through and connect directly into the remote system without the
need of having to enter the passphrase.
So now this is both secure and convenient. And, of course, I can use the
one key to access many systems. And even though I don't have many
systems, I do have some other systems, don't I?
I've got my SUSE system. So what we could do is jump out of this system, so
using the exit command to return through to my Ubuntu system,
go back on my Ubuntu system and repeat the ssh‑copy‑id. I don't need to
generate again, I just need to copy it to the.12 system. Still
password‑based authentication at the moment, but now because my
passphrase is already cached, I get to see the beauty of this that I get
straight into my Ubuntu system without the need of having to put in the
passphrase on subsequent attempts.
So this now is really convenient that I can access my range of
service that I need to manage from the one user account, vagrant.
And using my public key and private key pair for authentication, I
can easily access my systems.
And this is really what we wanted to take a look at, generating
the keys so we can do away with passwords,
copying those IDs with the ssh‑copy‑id, caching our
passphrases with the ssh‑agent, and then seeing how it all goes together with our authorized_keys file.