☰

SSH-Angriffe, wie landen ihre Benutzernamen in auth.log? (PW-Authentifizierung deaktiviert)

tag-icon • tag-icon ssh iptables public-key
SSH-Angriffe, wie landen ihre Benutzernamen in auth.log? (PW-Authentifizierung deaktiviert)

Dieser Computer ist also über Port 22 erreichbar (von überall).
Da Nachrichten über fehlgeschlagene Anmeldeversuche (Benutzernamen wie root, cgi, bash, production...) /var/log/auth.log überfluten, habe ich die Kennwortauthentifizierung von externen IPs deaktiviert (nur Authentifizierung mit öffentlichem Schlüssel).
Und das funktioniert, wenn ich versuche, mich von einer externen IP (ohne Schlüssel) per SSH auf diesen Computer einzuloggen, erhalte ich nicht einmal die Eingabeaufforderung für den Benutzernamen:

Berechtigung verweigert (öffentlicher Schlüssel).

Wie landen also all diese falschen Benutzernamen immer noch in 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, Fehlermessage 4 Alter war: Kein solcher Benutzer
5 4. Aug. 17:02:50 Host sshd[17190]: Fehlgeschlagenes Passwort für Root von 217.116.204.99 Port 40054 ssh2
6 4. Aug. 17:02:50 Host sshd[17190]: Trennung von 217.116.204.99 empfangen: 11: Tschüss [Preauth]
...
513322 7. Apr. 19:45:40 Host sshd[15986]: input_userauth_request: ungültiger Benutzer cgi [Preauth]
...

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

Antwort1

Wenn Sie keinen Benutzernamen eingeben und sich von einer Linux-/OSX-/BSD-Workstation aus verbinden, ist der Benutzername implizit (standardmäßig ist es der Benutzername, mit dem Sie angemeldet sind). Wenn Sie Windows haben und Putty verwenden, versuchen Sie die Verbindung herzustellen, ohne den Benutzernamen für die automatische Anmeldung festzulegen, und geben Sie einen Schlüssel ein. Sie werden nach einem Benutzernamen gefragt, um zu versuchen, das Paar abzugleichen.

Schlüssel ersetzen nur Passwörter, jeder ist mit einem Benutzer (und daher einem Benutzernamen) verknüpft, weshalb Sie die authorized_keysDatei unter finden ~/.ssh/.

Was Sie wahrscheinlich sehen, sind Angreifer, die etwas Ähnliches tun wie ssh bash@<your.server.ip>. Der Server sieht einen Benutzernamen, aber da kein Schlüssel vorliegt, wird ihm der Zugriff verweigert.

verwandte Informationen