CentOS release 6.6 and limit SSH by IP.
 

Hello.
I like to limit SSH connection to my server that use "CentOS release 6.6 (Final)". I Google it and found two ways: 1- use "hosts.allow" file 2- use "sshd_config".
Which one is better and more easy?

Thank you.

The latter. tcpd aka tcpwrappers support is discontinued in modern versions of OpenSSH server. You can do the same filtering with iptables instead. However, to keep everything in one place, you can modify sshd_config to accept or block connections from specific IPs. You might even put it inside a Match block. See the manual page for sshd_config for the authoritative specifics.

What why and how of tcpwrappers
by yours truly. 6.6 is eligible.

my personal preference is to use ipsets with iptables, works well on CentOS 6, but there have been issues with the ipset package in RHEL/CentOS 7.

With ipsets, instead of having to set-up a rule per ip, you can set rules per ipset and then add ips to the ruleset. For example you could do the following to get two groups for admins and developers with everything else blocked.

ipset -N admins iphash
ipset -A admins 10.0.0.10
ipset -A admins 10.0.1.10

ipset -N developers iphash
ipset -A developers 10.1.0.15
ipset -A developers 172.16.23.72

iptables -I INPUT 3 -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -I INPUT 4 -m set --match-set admins src -j ACCEPT -m comment --comment "Admins ipset group can connect all"
iptables -I INPUT 5 -p tcp -m conntrack --ctstate NEW --dport 22 -m set --match-set developers src -m limit --limit 12/hour --limit-burst 5 -m comment --comment "5 login attempts every 5 minutes" -j ACCEPT
iptables -I INPUT 6 -j DROP

of course to get to this level you would have to learn iptables and ipset but it gives you very explicit control over what you allow and do not allow to connect. To be fair the limit module still leaves me a tiny bit confused.

I'd be tempted to do it at iptables level as it's closer up the chain. That way you can block/reject/drop the traffic before sshd even has the connection to consider.

Then add layers, the more layers the better.

For example it's possible within .ssh/authorized_keys specify that a key is only valid from a specific IP address.

oh yes! Good point, you can also use DenyUsers and AllowUsers within the SSH configuration to lock down the users. My test box is down at the moment and don't have accessibility to my work test boxes from home but I would usually do something like...

printf "DenyUsers " >> /tmp/denies
# awk -F":" '{print $1}' | tr '\n' ' ' >> /tmp/denies
EDITOR /tmp/denies
-- manually move users you do want to allow, to next line with an AllowUsers
cat /tmp/denies >> /etc/ssh/sshd_config
rm /tmp/denies

restart ssh and test. This way you further fine tune down the security.

Nooooooo......

Create a group "sshusers", use AllowGroups sshusers in your sshd config and then just add sshusers as a secondary group to the users allowed access.

Fair enough, either way an extra layer of protection to lock down users. I just work with people who would probably get lost if we did it by group unfortunately, more so the junior technical engineers. Tho where I work we also lock things down on hardware or virtual firewall devices too, depending on the customer set-up, even more layers.

Sad and strange to hear. Assigning permissions at group level has been established best practice for decades, for what should be obvious reasons. If they can't handle groups, they should not have accounts until they prove themselves capable at remedial training or their replacements can be hired and the old accounts removed instead. This isn't about "security", this is about basic concepts needed to operate the machines they have gotten into. A metal shop makes sure anyone on the floor is both qualified to operate the equipment and follow best practices. This is not much different, just digital.

Tell me about it, I unfortunately am not responsible for recruiting. Management don't value engineering skills highly and look to always do what is cheapest rather than what is best meaning we get people who many have never had a real IT job before, let alone experience with Linux.

Well the team I am in, we are constantly complaining about many MANY issues. I couldn't really respond to this earlier while I was at work for obvious reasons but honestly every company has issues and if not for our sys admin teams (of which I am in one) the company would have failed a long time ago... anyways not gunna hi-jack this thread too far away. I am instead looking at other jobs.

Sorry apologies about doing things in a bit of a too simplistic way instead of a more functionally correct and secure method, the mindset is a bit off from where I'd like it to be sometimes.