SSH has become the de-facto standard for remote access. However, a default installation 1
of ssh isn't the most secure one, and 2
there are a few simple steps that can dramatically improve security. 3
I'll show you how to secure the open ssh server. 4
The server configuration file is located in /etc/ssh/ and it's called sshd_config. 5
This is the server configuration file. 6
To change anything related to the server, you have to edit this file. 7
After editing the file, you have to restart the server so that the new changes go into effect. 8
Before you start making any changes to the server configuration, I'd recommend you to make a backup 9
of the file. 10
I strongly recommend this, especially if you are a beginner. 11
Note that there is also a file called sshd_config, this one, 12
which is the configuration file of the ssh client and sshd_config is the configuration 13
file of the ssh daemon. 14
This d comes from daeman. So I'm opening sshd_config the of course s root. 15
Each line that starts with '#' is interpreted as a comment. Each line can consist of a configuration 16
option, a whitespace and the value for that option. 17
In this file the keywords are case-insensitive and arguments that contain spaces are to be enclosed 18
in double quotes ("). 19
And as it's explaining in the file, the strategy used is to specify options with their default values, 20
but leave them commented out. 21
If you want to override the default option, you have to uncomment that line and change the option. 22
Take a look at this line, which is commented out. The default value for the option Port is 22, 23
the port on which the server is listening and 24
if I want to change the default port 25
then I have to uncomment the line and change the value of this option. 26
Not all available options of the ssh demand are present in this file. 27
And if you want to read more about what a specific option does, then open the man page of sshd_config. 28
and search there for the option you are interested in. 29
Like this. 30
I'm searching for the option called allow users. 31
And I see the description of the option. 32
Let's get started! 33
These are my top recommendations for securing the server. Use a non-standard port for the server. 34
By default, the ssh daemon is listening for incoming connections on Port 22. For a hacker to determine that 35
ssh is running on your machine, he'll most likely scan Port 22; change it to a random port 36
and you'll avoid being seen by casual scans, but not by targeted attacks. 37
Of course, this is security through obscurity 38
and this is not considered a good security practice in general because changing the port does not make 39
your server more secure. 40
A hacker who is targeting you could scan all the ports using a tool like nmap and find the vew port. 41
However, in the case of ssh, when the vast majority of attacks are automated and not targeted, this 42
is highly recommended. 43
I'm uncommenting the line 44
and changing the port to something random. 45
Don't forget to make the required changes to your firewall rules to allow the New port if it's the case. 46
My second advice is to disable direct root login. 47
One of the most dangerous security holes you can have in your system is to allow direct login as root 48
through ssh. No matter how strong the root password is, there's always the possibility that the hacker can find the 49
password using a brute force attack. If you need root 50
access log in as a normal user and use the sudo or su commands to run commands as root. I'm searching 51
for 52
PermitRootLogin. 53
This line! The director login of root, is disabled by default, but you should check it anyway. 54
It's default value is prohibit password, which means that root can login directly using another 55
authentication method, not the password. 56
It could use public key authentication, for example. 57
This is acceptable, but I prefer to change it to no. 58
My 3rd advice is to disable password authentication entirely, if that's possible, and enable only public view 59
authentication. 60
This is considered way more secure. 61
This is not the simplest task 62
so there is a dedicated section on how to do it later in the course. 63
If it's not possible to disable password authentication on the server, then use only strong passwords 64
and that means random passwords with a length of at least 10 characters consisting of letters, digits 65
and special characters! Do not use dictionary words or combinations of such words, no matter the language. 66
Another advice is to limit users' ssh access. By default 67
all system users can log in via SSH using their password or public key even if there are only a few administrator 68
users that really need to access the system remotely. 69
This setting will limit the impact of an ordinary user having a weak password. Add the AllowUsers 70
option and then a list of allowed users, separated by space 71
Note that this option is not in the file, so I'm simply adding it. 72
AllowUsers 73
and the list of users. Another advice is to filter ssh access at the firewall level. 74
If there are only a few admins that uses ssh for remote management, then accept connection to the 75
ssh port only from a limited list of source IP addresses. These will be the source IP addresses from 76
where the admin will connect, stay home and work. Permit the entire network if the source IP address changes 77
or is dynamic. 78
Supposing I want to permit ssh access only from two IP addresses or networks, then the following 79
ip tables rules are required. I am becoming root. 80
iptables -A INPUT -p tcp --dport and the ssh port; I've changed the 81
port to 2278 82
-s and the ip address that will be permitted; I'll writea rendom one, - -j ACCEPT accept written in 83
capitals and the second rule for the second IP address that will be permitted. 84
And finally iptables -A INPUT -p tcp --dport 2278 -J 85
drop. 86
Now, only ssh connections coming from these two IP addresses will be permitted. 87
If you want to allow an entire network, use the network address instead of the IP address! Take a 88
look at the ip tables section where I'm diving really deep into it. 89
Another advice is to use ssh protocol version 2. 90
This is the default for the latest versions of Open Ssh, so you don't have to do anything, just don't 91
change it to version 1. 92
Then you should configure an idle timeout interval. 93
This is the interval in seconds after which if no data has been received from the client, the ssh daemon 94
will send a message through the encrypted channel to request a response from the client. 95
For example, if the idle timeout interval you are seting is 300 seconds, once the interval has passed, 96
the idle user will be automatically loged out. 97
Let's check if the option is already in the file. 98
And it's there. 99
So ClientAliveIntervale 300 100
and ClientAliveCountMax 0. 101
You can search for these options in the man page of sshd_config any time you want. 102
You can also take a look at MaxAuthTries, I am serching for MaxAuthTries; 103
This specifies the maximum number of authentication attempts permitted per connection and Max Startups 104
This option specifies the maximum number of concurrent unauthenticated connections to the ssh daemon. 105
There's also log-in grace time that could be of interest. 106
The server disconnects after this time if the user has not successfully logged in, and my final advice 107
is to always use the latest version of OpenShh. 108
Take all the steps described in this video and you'll end up with un ssh server that is secure 109
enough for most enterprise setups.