ataques SSH, como seus nomes de usuários terminam em auth.log? (pw auth desativado)

1

Portanto, este computador pode ser acessado na porta 22 (de qualquer lugar).
Como as mensagens que indicam tentativas de login com falha (nomes de usuário como root, cgi, bash, produção ...) foram inundadas /var/log/auth.log, desabilitei a autenticação de senha de IPs externos (usando somente autenticação de chave pública).
E isso funciona, ao tentar ssh nessa máquina a partir de um IP externo (sem chave) eu nem recebo o prompt de nome de usuário:

Permission denied (publickey).

Então, como todos esses nomes de usuários falsos ainda terminam em auth.log?

  1 Aug  4 17:02:48 host sshd[17190]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.116.204.99  user=root
  2 Aug  4 17:02:48 host sshd[17190]: pam_winbind(sshd:auth): getting password (0x00000388)  
  3 Aug  4 17:02:48 host sshd[17190]: pam_winbind(sshd:auth): pam_get_item returned a password  
  4 Aug  4 17:02:48 host sshd[17190]: pam_winbind(sshd:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error:

PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error mess 4 age was: No such user
5 Aug 4 17:02:50 host sshd[17190]: Failed password for root from 217.116.204.99 port 40054 ssh2
6 Aug 4 17:02:50 host sshd[17190]: Received disconnect from 217.116.204.99: 11: Bye Bye [preauth]
...
513322 Apr 7 19:45:40 host sshd[15986]: input_userauth_request: invalid user cgi [preauth]
...

link

    
por basic6 08.04.2014 / 12:55

1 resposta

2

Enquanto você não inserir um nome de usuário, se estiver conectando de uma estação de trabalho linux / osx / bsd, o nome de usuário é implícito (o padrão é o nome de usuário com o qual você está logado), sem definir o nome de usuário do login automático e apresentar uma chave, ele solicitará um nome de usuário para tentar combinar o par.

As chaves apenas substituem as senhas, cada uma delas associada a um usuário (e, portanto, a seu nome de usuário), e é por isso que você encontrará o arquivo authorized_keys em ~/.ssh/ .

O que você provavelmente está vendo é que os invasores estão fazendo algo semelhante a ssh bash@<your.server.ip> . O servidor vê um nome de usuário, mas como não apresenta uma chave, o acesso é negado.

    
por 08.04.2014 / 13:16