3

On a standard Linux install with OpenSSH, what is the default rate limit for SSH login attempts using password authentication?

How many passwords can an attacker guess per hour?

3

On every connection, there is specific limit of password prompts. It is defined by the MaxAuthTries option (default is 6). But you can't do all the attempts at once. After each failed one, you will get some time penalty (~3 seconds to run through the PAM stack with delay).

The attacker can issue the connections in the rate limited by the MaxStartups (default is 10:30:100, which will start rejecting connection if there is 10 unauthenticated connections open).

The LoginGraceTime option is unrelated for the attacker, because it defines only the maximum time before the connection is closed by the server, if the attacker does not succeed to authenticate.

The limiting factor here is mainly key exchange, which takes time because:

  • crypto involved takes CPU time -- depends on the server and client processors or accelerators
  • round trip times -- depends on the geographical distance

My fast test showed that establishing connection to the Raspberry Pi in the other room takes roughly 1 second. But it could go faster and SSHD can handle more parallel requests. The password prompt from localhost is almost immediate.

Let's say attacker can simply issue 10 connections in parallel, waits 1 second for prompt, writes one password, waits 3 seconds for the second prompt (or confirmation that the password was actually correct) (... repeats 6 times until it bails out). This takes 1 + 3 * 6 seconds (19 seconds) for 6 password attempts in single thread, 60 password attempts in 10 threads. Rounding up to the 180 in a minute and 10k in an hour in this optimistic case.

Note that the attacker can increase the amount of threads to 20 or more with quite low probability of rejection, but getting to the twice as much attempts (or even more, but can't go over 100). This is why the fail2ban exists.

  • 1
    Could the attacker use 100 threads and try 100k/hr? – Zaz Nov 21 '16 at 22:40
  • If both he and you have enough computation power and bandwidth, theoretically yes. – Jakuje Nov 21 '16 at 22:41
  • I have a 19 ms ping from a 2.3 GHz 64 bit server. On Ubuntu 16.04 with no MaxAuthTries setting in the relevant file, meaning the default applies, there are 3 attempts allowed (not 6) before a new ssh request is required. Using a keyboard (that is, not automated) there seems to be close to no delay between the 3 failed attempts. There seems to be closed to no delay for a new ssh request to be responded to with a prompt for a password. This implies your Raspberry PI estimates way off what is experienced with typical servers. – H2ONaCl Jan 27 '17 at 4:45
0

man sshd_config:

 MaxStartups
         Specifies the maximum number of concurrent unauthenticated con‐
         nections to the SSH daemon.  Additional connections will be
         dropped until authentication succeeds or the LoginGraceTime
         expires for a connection.  The default is 10:30:100.

         Alternatively, random early drop can be enabled by specifying the
         three colon separated values “start:rate:full” (e.g. "10:30:60").
         sshd(8) will refuse connection attempts with a probability of
         “rate/100” (30%) if there are currently “start” (10) unauthenti‐
         cated connections.  The probability increases linearly and all
         connection attempts are refused if the number of unauthenticated
         connections reaches “full” (60).
  • The default LoginGraceTime is 120s. Am I right in thinking this means 100 attempts can occur every 120s? i.e. 3k/hr, 72k/day – Zaz Nov 21 '16 at 18:52
  • Would the downvoter care to explain? Is this answer misleading in some way, or was it because Ipor just posted a quote? – Zaz Nov 21 '16 at 21:55
  • 2
    @Zaz Yes, it was me. This answer is only partial and does not bring any invention except of copy&paste from manual page. See my answer. – Jakuje Nov 21 '16 at 22:07
  • 1
    Though we thank you for your answer, it would be better if it provided additional value on top of the other answers. In this case, your answer does not provide additional value, since another user already posted that solution. If a previous answer was helpful to you, you should vote it up instead of repeating the same information. – Toby Speight Nov 22 '16 at 16:34

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.