How can I delay the retry response from SSH when a bad password is tried or unsuccessful login attempt. I wanted the delay to be 2-3 second more that usual.

I could not find any option in sshd_config file to achieve the same.

So can anyone let me know how should I go about it.

  • What OS you use? – kockiren Dec 10 '13 at 7:44
  • I am running on an embedded development board with Linux kernel 3.4.8. – Patha Dec 10 '13 at 7:50
  • The delay should become longer after each try. – Sören Sep 24 '18 at 19:55

If you block all user even block root you can add this lines to /etc/pam.d/password-auth or /etc/pam.d/sshd, in the auth section add this to block all user for 5 minutes:

auth        required      pam_tally2.so  file=/var/log/tallylog deny=3 even_deny_root unlock_time=300

Now add the following line to the account section:

account     required      pam_tally2.so

Finaly restart your sshd and it should work. After this you can check for fault logins with the command: pam_tally2 You will get this output:

# pam_tally2
Login           Failures Latest failure     From
userxy            4    12/10/13 09:52:31
|improve this answer|||||
  • 1
    But @kockiren I don't have /etc/pam.d/sshd/ on my box – Patha Dec 10 '13 at 7:56
  • 1
    Then try to use: password-auth, I update my answer – kockiren Dec 10 '13 at 7:57
  • I don't have /etc/pam.d directory on my box but could see /etc/login.defs. – Patha Dec 10 '13 at 8:01
  • 2
    @singh Then check where your PAM config lives. Might not be the same for all systems, surely if you've set up SSHD you're capable of locating the PAM config... – TC1 Dec 10 '13 at 12:49

You can try to add

auth       optional   pam_faildelay.so  delay=250000

to the pam config file for sshd (In Debian systems usually in /etc/pam.d/sshd) Delay value of 250000 are 0.25 seconds.

|improve this answer|||||
  • Thanks @noqqe but I don't have /etc/pam.d/sshd on my distribution – Patha Dec 10 '13 at 7:54

IPtables rules can be tweaked to achieve what you are trying to achieve.

Assumption: Your embedded linux has netfilter module compiled in and provided you know firewall concept and you used iptables before. root access is assumed. If you are sudo capable, append sudo infront of the commands.

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource

The syntax has no vebosity desired but the line instructs firewall police iptables that you want to append a rule onto the existing INPUT chain. The -p tcp argument indicates that this rule will apply only to TCP packets. Most of the rest of the arguments rely on the -m option, which stands for match and tells iptables that the rule applies to packets which match the specific attributes we’re looking for. Here, the rule will be applied to packets that signal the start of new connections headed for TCP port 22. If a packet matches those attributes, iptables will note the remote host’s address in a temporary list.

iptables -N LOG_AND_DROP

Above rule will actually perform an action using a different chain, and in order to append it, we’ll need to first create the chain which we did (e.g LOG_AND_DROP)

iptables -A INPUT  -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 20 --hitcount 4 --name DEFAULT --rsource -j LOG_AND_DROP

This rule tells iptables to look for packets that match the previous rule’s parameters, and which also come from hosts already added to the watch list. If iptables sees a packet coming from such a host, it will update the “last seen” timestamp for that host. The --seconds 20 and --hitcount 4 arguments are used to narrow further the hosts we want to block—if a host tries to connect four or more times within sixty seconds, it matches that part of the rule and we jump (-j) to the LOG_AND_DROP chain.

iptables -A INPUT  -p tcp -m tcp --dport 22 -j ACCEPT

Technically speaking, this rule isn’t necessary with the INPUT chain since default is set to policy ACCEPT for all unmatched packets. Fail-safe if you happen to build a restrictive firewall e.g. default reject.

Appending after getting feedback from @singh. I did not realise state has been evicted in favour of more techie conntrack (connectiontracking) module

Instead of e.g.:

-m state --state RELATED

-m conntrack --ctstate RELATED
|improve this answer|||||
  • Thanks kaji for your response but Do I need to add "iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource" to some configuration file? – Patha Dec 10 '13 at 8:14
  • Above mentioned codes are iptable rules. You could create a bash script, put those rules and fire away Or you could just copy-paste it one by one in that order. – kaji Dec 10 '13 at 8:26
  • Kaji I tried running these command but couln't find any difference ,also running first and fourth give me iptables: The state match is obsolete. Use conntrack instead. – Patha Dec 10 '13 at 8:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.