Em sshd_config, 'MaxAuthTries' limita o número de falhas de autenticação por conexão. O que é uma conexão?

2

Eu defino MaxAuthTries para 1 na minha máquina Linux. Então eu tentei ssh em minha máquina Linux de uma máquina diferente na minha rede local, mas ele falhou dizendo " Too many authentication failures ".

Estou assumindo que isso ocorre porque eu tive algumas falhas antes enquanto estava configurando as coisas, e elas ainda contam para o total.

A página man diz:

MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6.

O que é considerado uma conexão? Isso significa que você só recebe MaxAuthTries de um determinado endereço IP? Isso está se referindo a uma conexão TCP? Como posso matar a conexão para que eu possa criar uma nova e tentar ssh novamente?

link

    
por ptjetty 21.01.2018 / 06:34

3 respostas

3

No caso do SSH, uma conexão é uma conexão estabelecida com a porta TCP do sshd (geralmente a porta 22). Omce sshd pára de aceitar novas tentativas de autenticação, ele fecha a conexão e, neste momento, a conexão é feita.

Antes de um usuário fazer uma tentativa de autenticação, o protocolo SSH requer a negociação de criptografia e outras opções de protocolo, estabelecimento de chaves de sessão e troca de chaves de host. Assim, cada nova conexão requer um pouco não trivial de trabalho: uma tempestade de tentativas de conexão SSH de várias fontes certamente poderia ser usada para DoS um servidor.

Uma tentativa de autenticação é uma tentativa de qualquer método de autenticação atualmente habilitado na configuração sshd . Por exemplo:

  • se o cliente oferecer uma chave SSH para autenticação, cada tecla oferecida conta como uma tentativa.
  • se o método de autenticação Kerberos / GSSAPI estiver ativado, verificar se o cliente pode ser autenticado com ele conta como uma tentativa
  • cada senha digitada no prompt de autenticação de senha obviamente conta como uma.

Os dois primeiros podem causar a situação: se você definir MaxAuthTries para um e a autenticação Kerberos / GSSAPI estiver ativada, ela poderá consumir a única tentativa antes mesmo de tentar a autenticação de senha. Da mesma forma, se seu cliente SSH tiver uma chave de autenticação disponível, mas você não tiver adicionado sua chave pública ao ~/.ssh/authorized_keys do sistema de destino para o usuário de destino, a tentativa de autenticação de chave pública consumirá sua única tentativa e você nem tente testar a autenticação de senha.

pam_unix , a biblioteca PAM que normalmente lida com autenticação de senha, impõe um atraso de dois segundos após uma tentativa de autenticação com falha por padrão.

Se a sua principal ameaça for adivinhar worms e bots em outros sistemas comprometidos na internet, reduzir MaxAuthTries pode ser uma má jogada: como um bot não se cansa, ele sempre se reconecta e tenta novamente. Cada tentativa exige que você gaste alguma capacidade de CPU para negociações do protocolo SSH. Você vai querer garantir principalmente que o bot não terá sucesso , e secundariamente que o bot irá desperdiçar tanto tempo quanto possível naquela conexão existente, com custo mínimo para você . Permitir várias tentativas de autenticação em uma conexão, mas respondendo ... muito ... lentamente ... fará exatamente isso.

É também por isso que sshd solicitará uma senha do cliente, mesmo que a autenticação por senha esteja completamente desativada: o prompt é completamente falso e o cliente será rejeitado, independente da senha digitada. Mas o cliente não tem como saber com certeza.

É claro que, se você permitir muitas tentativas de autenticação em uma conexão, o bot poderá encerrar a conexão do lado, se o programador do bot tiver implementado um tempo limite para limitar a eficácia dessa defesa.

    
por 21.01.2018 / 13:33
1

Para ser amplo, uma conexão é definida como qualquer tentativa de se conectar como um determinado usuário.

O comando pam_tally ou pam_tally2 é útil aqui, dependendo de qual distribuição você está usando. O comando a seguir mostrará quantas falhas houve para um determinado usuário:

pam_tally --user=username

Para redefini-lo para um determinado usuário:

pam_tally --reset

Para todos os usuários:

pam_tally --reset user=username

Para verificar se foi redefinido:

pam_tally --username=user

A execução do comando pam_tally ou pam_tally2 sem opções mostrará todos os usuários com tentativas malsucedidas ou bloqueados. Não se esqueça de mudar para pam_tally2 caso você tenha esse.

    
por 21.01.2018 / 07:14
1

Esta é uma observação de bola de cristal, mas uma conexão é exatamente isso e, a menos que você defina explicitamente as opções de multiplexação de conexão e remanescentes ( ControlMaster , ControlPersist ) no cliente, ela deve terminar imediatamente.

O que eu suponho está acontecendo (e ssh -v pode ajudá-lo a verificar, procure por "Tentar chave privada") é que você deseja usar a autenticação baseada em senha nessa máquina. No entanto, seu cliente provavelmente tem um par de chaves para autenticação sem senha em ~/.ssh . As configurações padrão dão preferência a chaves por senha, então o seu ssh oferece sua chave, o servidor não gosta dela, e essa é a única tentativa fracassada permitida. (Variação do tema: talvez você tenha vários setups de keypairs e apenas um deles seja autorizado para o seu servidor.) Você pode usar -oPreferredAuthentications=keyboard-interactive,password para sobrescrever quais mecanismos de autenticação oferecer: se o cliente parar de sugerir que pode fazer baseado em chave, você deve solicitar a senha, para que possa efetuar login novamente para definir o valor no servidor mais alto.

    
por 21.01.2018 / 10:00