☰

Ataques SSH, ¿cómo terminan sus nombres de usuario en auth.log? (autenticación de contraseña deshabilitada)

tag-icon • tag-icon ssh iptables public-key
Ataques SSH, ¿cómo terminan sus nombres de usuario en auth.log? (autenticación de contraseña deshabilitada)

Entonces se puede acceder a esta computadora en el puerto 22 (desde cualquier lugar).
Dado que los mensajes que indican intentos fallidos de inicio de sesión (nombres de usuario como root, cgi, bash, producción...) han estado inundando /var/log/auth.log, he deshabilitado la autenticación de contraseña desde IP externas (usando solo autenticación de clave pública).
Y esto funciona, cuando intento ingresar a esa máquina mediante ssh desde una IP externa (sin clave), ni siquiera aparece el mensaje de nombre de usuario:

Permiso denegado (clave pública).

Entonces, ¿cómo es que todos esos nombres de usuario falsos terminan en 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 4 edad era: No existe tal usuario
5 4 de agosto 17:02:50 host sshd[17190]: Contraseña fallida para root desde 217.116.204.99 puerto 40054 ssh2
6 4 de agosto 17:02: 50 host sshd[17190]: Se recibió desconexión de 217.116.204.99: 11: Adiós [preauth]
...
513322 7 de abril 19:45:40 host sshd[15986]: input_userauth_request: usuario no válido cgi [preauth]
...

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

Respuesta1

Si bien no ingresa un nombre de usuario, si se conecta desde una estación de trabajo Linux/osx/bsd, el nombre de usuario está implícito (el valor predeterminado es el nombre de usuario con el que inició sesión), si tiene Windows y usa PuTTY, intente conectarse sin configurar el Ingrese el nombre de usuario automáticamente y presente una clave; le pedirá un nombre de usuario para intentar hacer coincidir el par.

Las claves solo reemplazan las contraseñas, cada una está asociada a un usuario (y por lo tanto a un nombre de usuario), razón por la cual encontrarás el authorized_keysarchivo en ~/.ssh/.

Lo que probablemente esté viendo son atacantes que hacen algo similar a ssh bash@<your.server.ip>. El servidor ve un nombre de usuario, pero como no presenta una clave, se le niega el acceso.

información relacionada