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?
    – user
    Dec 17, 2013 at 13:53
  • 1
    I wanted to prevent the possiblity of brute force attack.
    – Ram
    Dec 17, 2013 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.
    – user
    Dec 17, 2013 at 13:59
  • 3
    Dude, fail2ban uses the exact infrastructure that you already have -- ssh logs and iptables rules. Dec 17, 2013 at 15:10
  • 1
    I can see a delay maybe being useful. Consider this configuration: (1) Move sshd port to xx instead of 22, (2) Delay sshd's replies for 3 secs on port xx, (3) have an xinetd daemon listen on port 22, 23, and perhaps a few others known to be unused; any connection to more than one, implement an iptable ban on port xx. This would cause a port scan to not see anything on port xx; by the time sshd throws a reply, the port would already be blocked mid-connection.
    – erco
    Oct 6, 2018 at 20:40

3 Answers 3


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, 2013 at 14:25
  • 1
    @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, 2013 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, 2013 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, 2013 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, 2013 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.

  • Why are ssh-keys more secure than passwords? In order for this to be true aren't you assuming that the risk of a stolen password is higher than the risk that the SSH key and the computer it is sitting in become stolen ?
    – H2ONaCl
    Aug 21, 2022 at 2:42
  • @H2ONaCl Physical access will remove security. More common is a remote attack. And trying ssh-keys is way more difficult than trying passwords.
    – Nils
    Aug 22, 2022 at 20:50

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.

  • Good to know. The effective way is to introduce delay whether the authentication succeeds or not.
    – Sam Sirry
    Aug 17, 2022 at 10:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .