Ssh – hosts.deny ignored by MacOSX 10.8

mac-osxmac-osx-serverssh

I have been trying to set up my MacOS X Server, which I recently upgraded to Mountain Lion, to use denyhosts as I need to open port 22 to it. denyhosts is set up and adds entries to /etc/hosts.deny so I decided to add my laptops IP to it in order to verify that it actually works but I can still log in and my IP shows up in /private/var/log/system.log. I even rebooted the server once just to be sure there wasn't some service that had to be restarted.

I tried the following entries:

ALL: <my laptop's IP>
sshd: <my laptop's IP>
sshd: 127.0.0.1

My /etc/sshd_config has the following parameters set:

UsePAM yes
UseDNS no

I Googled if deny.hosts has been deprecated in OSX 10.7 or 10.8 but I couldn't find any indications that it has. Any ideas of what is going wrong or if there is an alternative way to achieve the same result?

Yes, a private key would solve this problem but for the time being I would like to stick to using password authentication. I also like the idea of denyhosts actually blocking access to all services running on the server and not just ssh.

Best Answer

I am also trying to get some information about getting denyhosts to work on Mac OS X Mountain Lion. So far I have not succeeded, but I know where to go next. Not sure I really need it though.

According to http://denyhosts.sourceforge.net/ssh_config.html:

In order to take advantage of DenyHosts, you must ensure that your sshd server has been compiled w/ tcp_wrappers support.

Which seems to not be the case anymore with OS X ML. https://discussions.apple.com/thread/4267535?start=0&tstart=0

This is why hosts.deny is ignored in Mountain Lion.

But I am not sure I want to go through installing libwrap through Mac Ports... Maybe I'll just change the SSH port to something higher to limit the onslaught of failed authentication attempts.

Once you are only accepting public-key authentication with sshd, you are really only losing some barely measurable performance and a bit more disk space through syslog.

Related Topic