Welcome back.
Now it's time to see how to configure the demon on Linux for public key authentication, the first step
is to copy the public from the machine where it was generated, Windows or Linux, to the Linux machine
where the SFH server is running in a special file.
In this example, this will be the Linux server to which we will authenticate.
I'll show you first for the case when the client is running windows and the then for the case when the
client is running Linux.
So if you've generated the keypad on Windows using Pooty key generator, just open the private key input.
Key generator I am opening, put the key generator and I am loading the private key.
And you see here, the public, for a pasting into open SSX authorized Kei's file.
Now, carefully, I am selecting the entire key and copy it to the clipboard.
Copy.
The next step is to move to the Linux server and paste the public contents in a file called Authorised
Underline Keys, which is in that SSX directory in user home directory.
Notice that in order to do this, you need access to the Linux machine with the user that will authenticate
using the Quebecer.
I am listing that SSA directory from user's home directory.
This is the user's home directory, that is S.H..
This is a hidden directory.
It starts with a that there is no key inside.
Also, notice that authorized underlined keys does not exist.
So I will create the file using VM, which is my preferred editor.
I'll create the file.
And I'm pasting the clipboard contents, which is the public key into the file.
And I'm saving the fight, OK, this, that's all, let's test it.
Let's check if the demon is running on the server system, Sitel status, SSX, and it's running.
We notice that the server is listening on Port 22 on each IP address of the server.
Broken windows.
I am opening Pooty and looking for connection.
Essayistic and authentication.
I'm clicking on the browse button and select the private key.
Now, on the main screen, I'm entering the IP address of the Linux server.
Let's check it.
OK, this is the IP address of the Linux server.
I'm giving this station a name and then save it so that I will not lose the settings like, say, Lennox
to this is the house name Save and I am clicking on Open.
They use their name student.
And I mean, it has successfully authenticated the user.
We see the message authenticating with public key and the key comment.
We've just configured the Essex public authentication for a Windows client in the Linux server.
Let's go ahead and see how to configure the Linux server to accept SSX public authentication if the
keypad was generated on another Linux machine.
So if the client runs on Linux, in fact, this is similar to the previous example.
The only difference being that the keys were generated on Linux, not on Windows.
OK, this is the client, the machine on which I've generated the keys.
And this is the server, the same server.
The first step is the same as in the case of Windows, and that is to copy the public from the machine
on weeks it was generated to the Linux machine to which we want to connect.
This is the machine where the keys were generated and this is the key.
I underline RSA, that pub the public.
I'll it on the other Linux machine using SICP.
Of course, I can also copy it to the clipboard and then paste it in authorized keys, but this time
I prefer to copy the public key file to the Linux server machine to use SICP on the Linux destination.
There should be an openness to select a server running and accepting connections on Port 22 or another
one.
We know of extra from the previous example.
So I am hoping the file SICP minus B and an upper case B ended up part of X default 22, but I use this
option because maybe your server is listening on another port and now the path to the file.
I will copy.
So the user's home directory, home student.
OK, that's the same as deal that SSA.
I'd underline risc that Bob.
Now, the user that will authenticate to the server student the IP address of the server.
And the remote part where the file will be copied, Tilde, I'll copy the file in the student's home
directory.
OK, it's asking for the password, SSX public authentication is not yet configured, so I'm authenticating
using the password.
OK, and the file has been copied.
This is the file I've just copied now on the Linux server.
I led the public key at the end of the file called Authorized Keys.
You can have more keys in authorized keys because there could be more users that authenticate to the
server and each user will have its own key keeper take care not to overwrite the file, but append tweaks
and.
And I'm using the kept comment, kept the public file double greater than symbol and the path to authorized
underline keys file.
Doppelt, greater than symbol, rejects the output of cat comment to the file, upending the redirected
output at the end.
Let's see the contents of authorized keys.
And we see their two public keys.
This is the public that was generated on Windows, the first example, and this is the public view that
was generated on Linux, the file I've just copied and appended to the end of this file.
OK, this is all I've configured public authentication on this Linux server.
Let's check if it works from the other Linux machine, which is the client.
I'll try to connect to the Linux server I've just configured into the Linux server should not ask for
the password, but authenticate the user using public key authentication.
SSX, the user student at the IP address of the server.
Perfect, I'm in.
I have successfully authenticated on the server.
If there is any problem, you can add minus the option to SSX comment, minus V V comes from verbose
and it will print out a lot of messages for you to troubleshoot the problem.
And you can look for any possible errors.
OK.
Also note that it's important to let the private key has their permission set only for the owner, if
the permissions are to lose, it could not work.
So change mode four hundred and the path to the private key.
OK, one last thing he recommended to disable password authentication on the SSA server, to do that,
you become a good.
Open the SSX demon configuration file, which is in Etsy, SSX, SAGD underlined config.
Don't forget this D from demand, there is also a file called SSX underlying conflict.
So without the and here I'm searching for password authentication.
OK, by default, yes, and I'll change it to no, no.
I have a disabled password authentication.
I'm saving the file and restart the service, the new configuration will become active only after restarting
the server system.
It'll restart S6.
Perfect.
Thank you, Voxel.