I wanted to provide login delay while login through ssh .I tried couple of ways of doing same but couldn't find desired result.

I tried steps provided by given link.


iptables -N SSH_CHECK
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK
iptables -A SSH_CHECK -m recent --set --name SSH
iptables -A SSH_CHECK -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP

I don't have pam module installed on my machine,so can't make any modification related to pam files

So any body let me suggest some other way to do the same?

I have bare linux kernel running on embedded platform.

  • Why do you want to introduce a delay? What is your ultimate goal? – a CVn Dec 17 '13 at 13:53
  • I wanted to prevent the possiblity of brute force attack. – Ram Dec 17 '13 at 13:57
  • 3
    Simply introducing a delay on new connections will not prevent a brute force attack. You need to look at tools designed to solve your actual problem. I'd suggest starting with looking at fail2ban which is specifically designed to react to repeated log entries by executing given commands, and is often used specifically to prevent brute force attempts at gaining unauthorized access. – a CVn Dec 17 '13 at 13:59
  • That is fine Michael but e I have to do it with existing infrastructure I have with me,How can I introduce a delay each time I connect through ssh. – Ram Dec 17 '13 at 14:02
  • 2
    Dude, fail2ban uses the exact infrastructure that you already have -- ssh logs and iptables rules. – Shadur Dec 17 '13 at 15:10

Method #1 - disable password logins

If you don't require allowing password logins, then simply disallowing them will give you the desired effect. Simply add this line to /etc/ssh/sshd_config:

PasswordAuthentication     no

Additionally you can limit password use to certain users using the Match operator in sshd_config:

Match User root,foo,bar
    PasswordAuthentication no
Match User user1,user2
    PasswordAuthentication yes

Method #2 - iptables

You can also use iptables to track failed login attempts and drop them after a certain threshold. This is similar to your example from hostingfu but is easier to understand.

$ sudo iptables -I INPUT -p tcp --dport <YOUR PORT HERE> -i eth0 -m state --state NEW -m recent --set
$ sudo iptables -I INPUT -p tcp --dport <YOUR PORT HERE> -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

NOTE: The first line basically creates a rule that only applies to packets used for new connection attempts on the ssh port. The second line says that if there are more than 4 attempts from an IP within 60 seconds, then any traffic from that IP should be blackholed. This solution doesn't care whether or not the attempts on different user accounts.

Method #3 - use PAM

I realize you said you don't have PAM available, but if you did, this is how you could delay failed login attempts. If your intention is to simply delay ssh login failures then you could use the PAM module pam_faildelay. This PAM module is generally included with the default mix.

On my Fedora 19 system it's part of the default installation.


Look for files related to pam_faildelay.

$ locate pam|grep -i delay

See what RPM they're provided by:

$ rpm -qf /usr/share/man/man8/pam_faildelay.8.gz


To create a delay on failure you'd simply add a line such as this to your sshd pam config file. Again on Fedora/CentOS/RHEL systems this file is located here: /etc/pam.d/sshd.

To create a 10 second delay:

       auth  optional  pam_faildelay.so  delay=10000000

A 60 second delay:

       auth  optional  pam_faildelay.so  delay=60000000


With a delay of 20 seconds using the above method, I changed my PAM sshd config file like so:

auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin
auth       optional     pam_faildelay.so  delay=20000000
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth
session    include      postlogin

Now when I login:

$ date
Tue Dec 17 09:16:30 EST 2013

$ ssh blah@localhost
blah@localhost's password: 
Permission denied, please try again.
blah@localhost's password: 

...Control + C....

$ date
Tue Dec 17 09:16:50 EST 2013


  • Thanks @slm but again I can't install pam module and my sshd authentication is not from pam.Would you like to suggest some other way around – Ram Dec 17 '13 at 14:25
  • @AmitSinghTomar - sorry I've expanded my answer. I was attempting to create a canonical answer to your question that covered all methods, not just yours alone. – slm Dec 17 '13 at 14:43
  • Thanks you again @slm for your detailes answer ,I am interested to following the second method you suggested .Will give a try and let you know the result,Also it give me a delay with very first attempt of login through ssh? – Ram Dec 17 '13 at 14:52
  • @AmitSinghTomar - no it should only delay after 4 attempts. When the --hitcount 4 is exceeded the rule will black hole the offending IP address for 60 seconds. – slm Dec 17 '13 at 14:58
  • One point I wanted to know from you ,for your 3rd method to work(PAM) ,do it require ssh authentication should happen through pam? – Ram Dec 17 '13 at 16:02

Disable passwords. No passwords, no brute-force attack.

You can use ssh-keys for logging in - which should be way more secure and way more difficult to hack.


On a clean install of Ubuntu 16.04 with openssh-server, there is already a delay for a wrong password attempt of greater than zero characters. The delay seems to be more than 1 second.

For a wrong password attempt of zero characters there is no delay so the attacker will determine immediately that your password is not the empty string if it is indeed not the empty string. Since the empty string is probably not allowed as a password they already know that so they are not going to try the empty string.

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.