To manage remote Linux servers. We need two things,
an SSH client on our local computer
and an SSH daemon running on the remote Linux server.
The SSH daemon is also called an SSH server. Since it serves user requests
with the client running locally,
we can connect to the open SSH daemon running on the remote server.
Our Linux machine is already running the open SSH daemon.
So let's jump straight into how we can configure that
the config file can be found at Etsy
SSH SSH D underscore config notice the D letter in this name.
It's placed there because the config refers to the SSH daemon.
There's also a config file for the SSH client
which can be found at SSH underscore config
note that this doesn't have the D after the S SHA subtle difference to be
aware of when editing SSH configs for the server part and for the client part,
because the Linux operating system usually includes both programs,
the SSH client and the SSH daemon.
So let's go through how we can configure the SSH server or DAEMON now
and we'll go ahead and put that D back on there and we'll open up the file.
The first important setting we'll notice is the port
number which the SSH daemon accepts incoming connections.
As we saw in previous lessons. This line is commented so it's not actively used.
But we can see that the default port is 22.
If we want to change this, we'd uncomment the line by deleting the preceding
number sign and then change the number to whatever we want.
And the next line looks like this
address family. Any.
Now, this setting name is a bit obscure,
but it gives us a chance to find out how
we can get more info about some config options here.
Let's exit the editor and then consult the manual for SSH D underscore config
now if we type a forward slash
and type in family,
we'll find this description.
Now we understand that this setting allows us to pick
which IP protocols we want enabled for our SSH daemon.
Any enables both IPv4 and IPv6
int just enables IPv4 and int six enables IPv6
only if we want to change password related settings.
We can search for the word password throughout this document.
Since the manual is open in the last pager,
we may remember that we can press N to move on to the next match.
If we search for password in this manual press n
a couple of times we'll end up with this result.
And this is password authentication
and it specifies whether password authentication is allowed.
And the default is yes.
Now that we know how to find and understand these config options.
Let's get back to our file.
If we only want to accept incoming connections on IPv4,
we would uncomment this and change it
and for IPv6,
we would change it to int
six.
Now, by default,
the SSH daemon listens for incoming connections on all of its available IP S
but let's say we have two IP S on our server.
We have 203.0 0.113 0.1
and that one is connected to the internet
and we have 10.11 0.12 0.9
that's only connected to our internal network at the office.
If we need SSH to only be accessible to employees from within our building
connected to that internal network,
we could tell our daemon to listen on only that IP address
so we could uncomment this line and change it to listen address. And the IP.
Now another option that is commonly tweaked is this one permit root login
by default.
It allows the root user to log in but
only if authentication is done without a password.
For example, using SSH keys.
That's why prohibit dash password is enabled by default here to
disallow the root user from logging in through SSH entirely.
We can change this to permit root login.
No, now SSH supports many login mechanisms,
but the two most popular are passwords and SSH keys.
Now if we scroll down,
we'll see this
now, by default, password logins are allowed,
but some administrators prefer to
disable these by changing password authentication
to know.
However, there's another option that might still make password logins possible.
Further down, we can see this,
we have KBD interactive authentication.
The difference between these is subtle
with password authentication set. TS
users can log in by using a password
but the SSH daemon won't check if the users actually type the password.
For example,
the user can just use an automatic way of sending
the password without actually typing it at the keyboard,
KBD, interactive authentication.
On the other hand,
ensures that the user actually types the password while logging in.
So if we disable both keyboard,
interactive authentication and password authentication,
we disable password logins entirely,
which means users would only be able to log in with
SSH keys which are usually much more secure than passwords.
These keys are basically files with a very large unique code inside.
Only the person that has this unique code can log in as that user.
And we'll see how that works. Later in this lesson
on Linux,
we have the option to run a graphical application on
a server but show its window on our local screen.
It's basically like teamviewer,
but one for an application window instead of the entire desktop,
this is called X 11 forwarding.
And here we can see it's currently enabled under X 11 forwarding equals yes
Now,
the settings we looked at are global that is they're applied
to all users that try to log in through SSH,
but we can define specific settings for specific users.
Now, let's say we use this global setting password authentication. No,
no user would be able to log in without a password.
But let's say we want to make an Exception for a single user named Aaron.
We could scroll down and see an example of how we could do this.
And it's right here at the bottom example
of overwriting settings on a per user basis.
So for our purpose,
we could say Matchy or Aaron
password authentication. Yes.
And this would create an Exception for Aaron.
Now, this user can log in with his password while all the other users can't
let's exit the editor.
Now, every time we change this config file,
we need to reload the SSH daemon so that it can apply our new settings.
Now,
it's also worth noting that some additional files
might override the settings you just added.
For example, in my case,
I couldn't disable password logins just by changing the main config file.
And that's because in this SSH D underscore config dot d directory,
there is a file called 50 dash cloud dash
init.com.
And
in that file contain the following config line
password authentication. Yes.
So basically, even if I set password authentication to no, in the main config file,
this additional configuration file would be
loaded next and reenable password authentication.
So explore this directory first to make sure that
nothing is clashing with the settings that you want.
Now, let's jump over to the other half of the story.
We've changed settings for the receiving part, the SSH daemon or server.
But what about the part connecting to the server? The SSH client,
it also has some configurations we can adjust.
Now, windows,
10 Mac Os and Linux operating systems all come with an SSH client preinstalled
on Windows. We can open up the command prompt.
While on Mac Os and Linux, we open up a terminal
and then we then type SSH
and we're actually executing the SSH client, which is a text based program.
The client keeps some of the files in the SSH directory of each user.
This client keeps some files in the SSH directory of each user.
For example,
if we're logged in and the user has a home directory in slash home slash Jeremy,
these files will be in slash home slash Jeremy slash SSH.
Now here I use the tilde for a shortcut,
but as you can see, it's slash home slash Jeremy slash SSH.
This applies to a Unix like operating system such as Linux or macOS
in
Windows. This directory will be at C users, Jeremy dot SSH.
Now, back to Linux,
there are usually no config files created by default for the SSH client
and I mean locally for each user.
This is because there's a config file for the SSH client,
but it's applied globally for all users on this machine.
And we'll get to that later in this lesson,
we can manually create a custom SSH client configuration for our current user.
We just need to create a file called config and place it in the dot SSH directory
to see what options we can place in this file, we can enter this command
notice there's no D after the
SSH
for demo purposes, we can take a look at our servers. IP
and we'll use this in our next config
let's change to our user's home directory
and it looks like I'm already here
and then we're going to create a config file.
Now, whenever we log into an SSH server, we need to use a command like SSH,
Jeremy at 10.0 0.0 0.186.
Now, this is not an issue when we manage one or two or three servers.
But if we need to connect to many more,
we'll probably forget what username and IP address to use for each connection
so we can use the config file and write this inside.
Now, if you're following along with this exercise,
replace the IP that I put in here with the IP of your server
and replace Jeremy with your username.
OK. We'll save this file.
Now, after we save this file, we'll need to change the permissions like this.
The
SSH
client requires that this file cannot be read by other users for security purposes.
But now we don't need to remember the IP and username for each server.
We just have to remember the name for the host that we defined in our config
we can connect to our server with this command.
And here this is the first time we're connecting.
So it doesn't recognize the fingerprint
and we'll say yes.
And we're in now, let's loglog out from the second SSH session.
Moving on to our next topic,
we saw how to create custom settings for the SSH client for a specific user.
But what about global settings for the SSH client that's applied to all users?
Well, that can be found in this file.
Now, even though these lines are commented, they show us the default values.
For example, we can see port 22.
That means by default,
the SSH client will try to connect to port 22 on the remote server.
But let's say that our internal network of
servers uses an alternate port number 229.
Well, we can uncomment this
and change it to 229.
Now, whoever is using the SSH client installed on our Linux machine
when they enter in SSH, Jeremy at an IP address,
they'll be connected to port 229 on the remote server instead of port 22.
But it's not recommended to modify this file.
A future upgrade of the SSH client might overwrite the changes.
So a better way is to add a new config file in this directory.
Now, remember this directory that we saw earlier,
let's create a new config file
and here we can define our new default port
and that's it.
And this is a great way to put in custom settings for all of the users.
Now, on to our next topic, what if we want to log in with SSH keys instead of passwords?
First, we need to generate a private and public key pair on the client side,
which is our local computer.
We'll do this directly on our Linux server.
But it's useful to know that this command will work the same on mac Os or Windows.
And the command to generate the key pair is SSH
dash keygen.
Now, at the prompts, we can simply press enter even for the passphrase.
Although in a real scenario, we would want to pick a passphrase too.
The pass phrase is generally a password that can
be used to encrypt the SSH private key.
And this can protect against a scenario where
someone steals that file without the password.
They cannot decrypt the file that contains the key
so they still can't log into your servers.
And now you can see that we've created this ID underscore E 25519
and ID underscore
25519 dot pub.
Now,
if we want to be able to log in to our server with our private key
we have to copy the public key to that server and we have two options.
The easiest is to run this command on our local computer
SSH dash, copy, dash ID, Jeremy at and then the IP address.
Now, in this case,
the content of dot SSH id underscore ed 25519
dot pub would be copied over to Jeremy's home directory
and it would be stored in a file called dot SSH slash authorized keys.
We can add many more public keys to that file.
Let's go ahead and do this.
All right. And it says number of keys added.
Now, try logging into the machine and we'll do that
and I'm able to log right in.
Now, let's check that authorized keys file.
And there's my key.
Now, we can add a lot more public keys to this file.
Like if we have three employees that should be able to log in as Jeremy to the server,
we just add all three of their public keys to this authorized keys file.
Now, sometimes the SSH dash copy, dash id command cannot be used
in that case.
The alternate solution is to edit the authorized underscore keys file manually.
We will exit from here.
We're back on our client machine
and we need to copy the contents of our
public key which is stored on our local computer
in that dot pub file.
So we'll copy this information
then SSH into our server
and we would add it in here
and we'll pretend that we didn't run that command earlier. So this file will be blank
and we would just paste it in here.
And after we save the file, we need to change its permissions
and that's it.
Now,
whoever has the private key that corresponds to the public key that
we just added can log in through SSH to that user's account.
Now, as a note,
I just hit enter when it came to putting in a
passphrase so I can just SSH directly into this machine.
I wouldn't recommend that if you type in your passphrase, then you must have that
key
and then the pass phrase to get into the server.
Now, it's also worth noting another important file in the dot SSH directory.
Now, you might have noticed the first time we log into an SSH server,
we get a message like this
where it says the authenticity of the host cannot be established.
Now, once we accept this fingerprint,
it will be stored in a file called known underscore hosts.
The next time we log in,
it goes right in
because the SSH client compares the fingerprint,
it's saved with the fingerprint announced by the server.
If they match that means we're connecting to the same server.
If they don't,
either it's someone Impersonating our server or in the most typical scenario,
they just reinstall the operating system for our server
for security purposes, the SSH client won't let us log in.
If the fingerprint does not match,
we can remove an old fingerprint from that file with a command like this
SSH dash
keygen
dash uppercase R and the IP address,
this will remove the fingerprint stored for the server
with the IP address 10.0 0.0 0.2 51.
And there it's prompting for a fingerprint again.
Now if for some reason we want to remove all fingerprints,
we can delete the entire file.
And that concludes this lesson on configuring SSH servers and clients.