Purposely Delay SSH Prompt After Bad Password
 

How can I delay the retry response from SSH (for, say, 10, 20 or 30 seconds) when a bad password is tried by a whacker? I mean, when I'm getting hit by 10 or more break-in attempts, is there some way to make SSH delay the next try from the site that's trying?

I seem to remember something about this but haven't been able to find it and, so far, reading the SSH documentation hasn't been too helpful.

I have DenyHosts running (that puts entries in /etc/hosts.deny after a few tries to break in) and I completely block China, Korea and a few others that are a constant annoyance with IPTABLES but I do get hit pretty much every day and would like to discourage the bastards as much as possible (the hits are a second or so apart which tells me they're automated and I figure delaying the response will discourage 'em).

For example, here's the overnight entries from /var/log/messages (the "refused connect" are from /etc/hosts.deny entries generated by DenyHosts):

Hi

You can use fail2ban

Cheers

Hm, interesting... kind of does the same thing as DenyHosts. I'll give it a shot and see what's what.

Thanks

You should also consider disabling root login in sshd_config and disabling password authentication. Together with denyhosts this significantly reduced the number of these messages for me (as well as improving my security).

Brian

One way of limiting SSH attacks is to change the port your SSH listens on, to something like 52022. This should foil the automated attacks at least.

To get back to your original question, please see the manpages for pam_faildelay(8). I haven't used it, but it appears you can add it to the auth stack for a PAM-enabled service to insert an arbitrary delay following an authentication failure.

[ p.s. I'm writing this from a Fedora system. The module I mentioned may or may not be included as part of a base Slackware install. ]

Slackware does not use PAM.

Regards

Thanks for all the input (actually, I do have PAM installed, need it for VMware and I'll give that method a shot).

I did find the following at http://www.aerospacesoftware.com/ssh-kiddies.html (inserted at the end of /etc/rc.d/rc.local:
Seems to work, it starts delaying the password prompt after the default 3 tries in sshd_conf for one minute (kinda eternity in confuser-land). Probably needs some fiddling and tweaking, but it does seem to work when I flog it from another intranet server.

Also, changing the port is a good idea (suggested all over the place in fact) and I'm going to experiment with that, too. Really looking for the quickest, most effective and reliable method (in keeping with the simplicity and effectiveness of DenyHosts, which works like a charm), and the port change may just be that.

And, lastly, I think I can live without the root login (although I do tend to use that now and again); can always connect as "me" and then "su -" to accomplish what I need to.

Actually, SSH does delay attempts to login. You don't need very much delay to make a brute force attack infeasible, and of course you're not using something easily guessable, right?

rc.local might be a little late in the boot process.

rc.firewall is where you probably should put your firewall rules. Look for the call to it in rc.inet2.

Very nice
Yes, much safer I think. Disabling password-based authentication altogether is even better, and easy to do.

Brian

I second moving ssh to a different port and using pub key auth.

I probably misstated "root login;" I only use public-key on all the machines I have access to. Much easier flipping back and forth when you need to, methinks. Too, my passwords are (more-or-less) uncrackable; Both the "old" Crack and the modern John the Ripper have run for about 24 hours trying to crack them and neither as been able to so I kind of figure they're good.

Dealing with these idiots can be time-consuming; among the reasons I've relied on DenyHosts for much of the work is that it not only identifies and denies (in /etc/hosts.deny) the bad guys automagically, it also merges my individual experience with other DenyHosts sites around the world; thus, a much larger pool of bad hosts is maintained. That's nice.

I'm always kind of loathe to fiddle with base settings (unless I have to) because then I have to remember what I did and why I did it on the next update or release. Of course, given the state of things in this world, you have to protect yourself; that's why you have locks on your doors and that's why you have firewalls and a plethora of tools on your systems to keep the jerks out of your pants. DenyHosts is one of those, IPTABLES is another and "fine-tuning" SSHD is yet another on top of those. Tis a sad thing, indeed.

So, we turn off root login in SSH, have DenyHosts running (they do try to walk system accounts, too), change the port SSHD listens on, add IPTABLES entries to /etc/rc.d/rc.firewall (thanks, Richard!), think about actually using PAM and setting pam_faildelay (well, not yet, but maybe), fiddle with fail2ban and see what that does, keep monitoring the logs and keep our collective fingers crossed, dammit.

Thanks to all for the ideas.