So I installed denyhosts on my system and I ssh to it fine. Then all of a sudden I got an email saying my ip was added to the /etc/hosts.deny file.

I have no clue why. I did not fail the login. So I had an open session and put it in the /etc/hosts.allow file and tried to ssh back in no problem.

Then I logged out and all of a sudden I got the email saying my ip was added to the hosts.deny again. Now I am kicked out of the system..

I am guessing I cannot get back in until I get to the console and remove it. I can power on and off the system remotely but I enabled the chkconfig denyhosts on option so it starts on reboot. No remote console is setup.

So it looks like I am hozed until I can get to the console, bummer as I was trying to set up a spacewalk server on it. I cannot get to the console for a few days so if anyone has ideas how I can get back in let me know. But denyhosts seems to be working as designed.

This was a default install I did not configure anything funky. Just changed the email to root and started it.

I thought about changing my client IP but that wont work as I only have ssh passed on my router to that IP so if I change the client IP I wont get into my routing machine.

I think i answered my own question but just thought I would ask.

I guess my real question is why would denyhosts block my IP when the login did not fail and how do i configure it so this does not happen again.

I'm going to the denhosts site and look around. This is the first time after 5 installs this has happened to me.

Try adding your remote ip to hosts.allow, and see if this works that's how i have mine as I think I read somewhere that the system checks hosts.allow before hosts.deny, thats my .02 cents.

0 members found this post helpful.

so this looks like what i need to do when i get back to my console.

How can I remove an IP address that DenyHosts blocked?

If you have been accidentally locked out of one of your hosts (because DenyHosts has added it to /etc/hosts.deny you may have noticed that simply removing it from /etc/hosts.deny does not in itself correct the issue) since DenyHosts keeps track of the attempts in the WORK_DIR files. In order to cleanse the address you will need to do the following:

1. Stop DenyHosts
2. Remove the IP address from /etc/hosts.deny
3. Edit WORK_DIR/hosts and remove the lines containing the IP address. Save the file.
4. Edit WORK_DIR/hosts-restricted and remove the lines containing the IP address. Save the file.
5. Edit WORK_DIR/hosts-root and remove the lines containing the IP address. Save the file.
6. Edit WORK_DIR/hosts-valid and remove the lines containing the IP address. Save the file.
7. Edit WORK_DIR/user-hosts and remove the lines containing the IP address. Save the file.
8. (optional) Consider adding the IP address to WORK_DIR/allowed-hosts
9. Start DenyHosts

Note: Not all of the WORK_DIR files will contain the IP address so you may want to use grep to determine which files contain the IP address.

Actually I ssh to my outside the FW system then ssh from that to the other system.
So I will need to add that machines IP to the denyhosts cfg files.

Just not sure why it locked me out when my id/passwd as entered in correctly.
I'll fix it tonight if all goes as planned. Then its on to build a spacewalk server and an http server may be smtp server too. we will see.

I also used to use denyhosts and never seen that issue before. Is there any other traffic going to your sshd when you aren't sshing into it? Was just curious.

Also have you read: denyhosts vs fail2ban

Just brought it up because I didn't know what the difference was until I read that.

nomb

1 members found this post helpful.

no nothing else just me. on the system. I have since gotten back into the server from the console and hard coded one of my internal ips in hosts.allow so i will have no issues at least I hope not.

Nice link. I had seen that fail2ban has options for tcp-wrapper but as IPTables was working nicely for me I left it with that. However fail2ban only bans after the user has failed to connect also.

How can you ban someone who hasn't tried to connect yet?

The post wasn't about denying before or after the user fails a login. It was about when you do deny, do you let the packets get into the daemon or stop them at the firewall?

Either way both hostsdeny and fail2ban watches your ssh logs for failed logins. Neither just 'magically' know which ip to block before they try to login. If that is how he is using denyhosts, it is possible fail2ban may be a better option.

If you are trying to ban someone before they connect, I would think that guide still applies and add entries into iptables over hosts.deny.

1 members found this post helpful.

For future reference, I prefer fail2ban to denyhosts. Fail2ban expires old bans in case of accidental lockout, plus I like the idea of banning at the firewall level rather than through tcp_wrappers for the reasons mentioned above.