"In this HowTo I will show how to install and configure DenyHosts. DenyHosts is a tool that observes login attempts to SSH, and if it finds failed login attempts again and again from the same IP address, DenyHosts blocks further login attempts from that IP address by putting it into /etc/hosts.deny. DenyHosts can be run by cron or as a daemon. In this tutorial I will run DenyHosts as a daemon."
To read all comments associated with this story, please click here.
Member since:2006-02-15
Uhh...that doesn't stop someone from just checking all open ports and then test if there's ssh server running on one of them. Then you are again open to dictionary attacks, or brute force. I myself just use the default port 22, and have DenyHosts block access to every service on my machine for any IP which tries to break in. My /etc/hosts.deny is already quite big ^^
Oh, and just as a side note to anyone who's a newbie to these kinds of things: do NOT allow root to login remotely from anywhere..It's just too easy to try to guess the root password using brute force attacks..
Member since:2005-07-08
Member since:2006-01-27
Member since:2005-07-11
There's nothing wrong with allowing root logins via ssh ... if you use keys instead of passwords, and put long passphrases onto your private keys. Newer versions of OpenSSH include a nice without-password option to the PermitRootLogin which only allows root logins using keys ... no password allowed.
Member since:2005-07-06
> Uhh...that doesn't stop someone from just checking
> all open ports and then test if there's ssh server
> running on one of them.
Well, but the funny thing is: Those kids floating your log files don't do that, so for cleaning up your logfiles for being able to see real treats just moving the port helps.
Ok, but your other suggestion, disabling root login (or at least disabling password authentication) is pretty right. So just another indication, that DenyHosts is overkill for common secure shell setups. Remember: DenyHosts is yet another component which might break...
Member since:2005-07-20
>This solution is overkill as there is some much more trivial solution to stop those kids trying to breaking automatically: Move your secure shell daemon to another port than 22. At least for me this tiny change blocked kids from one second to another.
That doesn't really work if you have to provide shell access for hundreds of users some of which are somewhat non-technical.
Member since:2006-01-11
Member since:2005-11-05
On your *secure* host with ssh on port 1234, try running 'nmap -sV' against it and notice that is shows ssh + the version number with absolutely no problem. Like client side only, security through obscurity is NO security at all.
A better idea would be:
1.) Create a normal unprivileged user on the server with full sudo access.
2.) Use the 'AllowUsers' directive in the sshd_config to only allow that certain user.
3.) Make sure to uncomment 'PermitRootLogin no'
4.) 'ps -ef | grep sshd' and find the pid of the ssh daemon.
5.) 'kill -HUP xxxx' where xxxx is the pid of sshd to force it to reload it's configuration without restarting.
If you wanted to be really crazy, you could disable password authentication alltogether and use key based auth only. That is the most secure method.
Edited 2006-02-19 13:53
Member since:
2005-07-06
This solution is overkill as there is some much more trivial solution to stop those kids trying to breaking automatically: Move your secure shell daemon to another port than 22. At least for me this tiny change blocked kids from one second to another.