I know that when you attempt to log in to a device via SSH, upon inputting an incorrect password, you must wait several seconds before you get another attempt. This is obviously a deterrent against brute force attacks. But what's stopping attackers from starting multiple sessions with the SSH server, then only guessing the password on the first attempt?

In my experience, there's no delay when you're prompted for the password the first time. So could an attacker just use multiple SSH sessions, and only guess the password using that first attempt?

1 Answer 1


While there is no delay before the first prompt, there is still the same delay that comes from calculating the hash of the attempted password. Without parallelism, that is still the fastest one can get. This is also one reason to use cost-based password hashing.

Regarding parallelism, there are other limitations coming from the sshd_config(5):

Specifies the maximum number of open sessions permitted per network connection. The default is 10.

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

By default an attacker could only have 10 concurrent attempts waiting for the hash calculation. The former limits an attack from a single IP address while the latter limits all concurrent attacks.

As a side effect of these limitations, severe brute force attacks could cause denial of service (DoS) for legitimate users. It is not wise to let the brute force continue, and stopping it with, e.g., Fail2Ban will mitigate the DoS, too. Frankly, SSH brute force is part of the background noise of the Internet, and everyone should harden their configuration against it by limiting the connectivity and preferring key based authentication.

You must log in to answer this question.

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