Back on ssh topic, i think this is third or perhaps the fourth article regarding ssh, one of my favorite tools on a Linux server, and that a lot of times is not used or configured properly. In this small guide i’ll show you some setup to make your ssh server a bit more safer from the most common attacks.
In particular i’ll show the configurations for openssh that is the most common and used ssh server in all Linux distributions but, as small suggestion, if you are using a VPS and you want to save some memory check also dropbear, it’s a valid alternative to openssh and it saves some space in your ram.
For Debian and Ubuntu (but also for other distributions) the configuration file it’s located at /etc/ssh/sshd_config and at the end of all changes you’ll need to restart ssh daemon.
1 – Disable root access
I’ve always thought that direct connection with root account it’s a bad habit, because
- Attackers already know the username, so just need to discover the password
- If the account it’s hacked your machine it’s FUBAR
- If more than 1 people administers that machine it’s better to use sudo to track who does things.
So to disable direct root connection set this option:
PermitRootLogin no |
2 – Enable only some users or groups
Probably on your machine only a few users must login via ssh, if they are just a few you can use the directive:
AllowUsers username |
This option can be followed by a list of user name patterns, separated by spaces.If specified, login is allowed only for user names that match one of the patterns.`*’ and `?’ can be used as wildcards in the patterns. or if you want to manage the access via a group you can use another option:
AllowGroups groups |
Like above this option can be followed by a list of group name patterns, separated by spaces.If specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns.`*’ and `?’ can be used as wildcards in the patterns
These 2 directives are really useful because you don’t have to worry anymore of the products that when installing set up a new account, maybe with a weak password.
3 – Change the standard port
Another safety rule is to change the default port, ie 22, since most of the automated tools perform Brute Force attacks or Dictionary Attacks right on this port.
It’ better to use a port above 1024, because the port scanners usually scans the first 1024 ports, so we’ll use the 2222.
So we change the directive substituting 2222 to 22
Port 2222 |
Now to connect to yourserver.com with your ssh client you have to specify the port, this is easily done adding the -p option to the openssh client:
ssh -p 2222 yourserver.com |
Conclusions
And that’s all, as you can see these are really 3 easy steps, but they will make your server more secure from the most common attacks.
Popular Posts:
- None Found
4th should be edit hosts.allow
Do you really need to allow the whole planet to connect?
On my Mom’s ssh server only hosts allowed are connections from my ISP (US – small phone cooperative). Even though her router only works with port 22 all attempts to connect but mine have seen “connnection refused”. Even if your ISP is a big US company this would drop all South America, Africa, Europe, Asia connection attempts.
hosts.deny of course is ALL:ALL
I suggest to disable password authentication and use only public keys auth so you don’t have to bother for weak passwords, brute force attacks or someone looking from your back.
You forgot about using private-public keys and disabling password login. I’ve never heard a single report of anyone brute-forcing a public/private key, but passwords are brute-forced daily.