Em todas as conexões, há um limite específico de prompts de senha. Ele é definido pela opção MaxAuthTries
(o padrão é 6). Mas você não pode fazer todas as tentativas de uma só vez. Após cada falha, você receberá uma penalidade de tempo (~ 3 segundos para percorrer a pilha do PAM com atraso).
O invasor pode emitir as conexões na taxa limitada pelo MaxStartups
(o padrão é 10: 30: 100, que começará a rejeitar a conexão se houver 10 conexões não autenticadas abertas).
A opção LoginGraceTime
não está relacionada ao invasor, porque define apenas o tempo máximo antes de a conexão ser encerrada pelo servidor, caso o invasor não tenha êxito na autenticação.
O fator limitante aqui é principalmente a troca de chaves, o que leva tempo porque:
- a criptografia envolvida leva o tempo da CPU - depende do servidor e dos processadores ou aceleradores clientes
- tempos de ida e volta - depende da distância geográfica
Meu teste rápido mostrou que estabelecer conexão com o Raspberry Pi na outra sala leva aproximadamente 1 segundo. Mas pode ser mais rápido e o SSHD pode lidar com mais solicitações paralelas. O prompt de senha do host local é quase imediato.
Digamos que o invasor possa simplesmente emitir 10 conexões em paralelo, aguardar 1 segundo por prompt, escrever uma senha, aguardar 3 segundos pelo segundo prompt (ou confirmação de que a senha estava correta) (... repete 6 vezes até que para fora). Isso leva 1 + 3 * 6 segundos (19 segundos) para 6 tentativas de senha em thread único, 60 tentativas de senha em 10 threads. Arredondando para 180 em um minuto e 10k em uma hora neste caso otimista.
Observe que o invasor pode aumentar a quantidade de encadeamentos para 20 ou mais com uma probabilidade de rejeição bastante baixa, mas chegando às duas vezes mais tentativas (ou até mais, mas não pode ultrapassar 100). É por isso que o fail2ban
existe.