☰

Ataques SSH, como seus nomes de usuário acabam em auth.log? (autenticação de senha desabilitada)

tag-icon • tag-icon ssh iptables public-key
Ataques SSH, como seus nomes de usuário acabam em auth.log? (autenticação de senha desabilitada)

Portanto, este computador pode ser acessado na porta 22 (de qualquer lugar).
Como as mensagens indicando tentativas de login malsucedidas (nomes de usuário como root, cgi, bash, produção...) têm inundado /var/log/auth.log, desativei a autenticação por senha de IPs externos (usando apenas autenticação de chave pública).
E isso funciona, ao tentar fazer ssh naquela máquina a partir de um IP externo (sem chave), nem recebo o prompt do nome de usuário:

Permissão negada (chave pública).

Então, como todos esses nomes de usuário falsos ainda acabam no 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, bagunça de erro 4 idade era: usuário inexistente
5 4 de agosto 17:02:50 host sshd [17190]: falha na senha para root de 217.116.204.99 porta 40054 ssh2
6 4 de agosto 17:02: 50 host sshd[17190]: Desconexão recebida de 217.116.204.99: 11: Tchau, tchau [preauth]
...
513322 7 de abril 19:45:40 host sshd[15986]: input_userauth_request: usuário inválido cgi [preauth]
...

http://paste.debian.net/92403/

Responder1

Embora você não insira um nome de usuário, se você estiver se conectando a partir de uma estação de trabalho Linux/osx/bsd, o nome de usuário estará implícito (o padrão é o nome de usuário com o qual você está logado), se você tiver o Windows e usar o putty, tente conectar-se sem definir o Nome de usuário de login automático e apresentação de uma chave, ele solicitará um nome de usuário para tentar combinar o par.

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

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

informação relacionada