So wehrt man arglistige Log-in-Attacken per OpenSSH ab

Die Sicherheitsvorkehrungen lassen sich hier sogar noch weiter verschärfen. Dazu werden nicht nur die anmeldeberechtigten Benutzernamen angegeben, sondern auch der jeweilige Host, von dem aus ein Zugriff gestattet ist. Das funktioniert durch eine Berechtigungsangabe nach dem Muster Benutzer@Host.

Lautet der Eintrag beispielsweise joe@10.0.5.1, dann ist für das Benutzerkonto joe ein Zugriff nur über Verbindungen von der IP-Adresse 10.0.5.1 aus möglich. Man kann hier auch mit Platzhaltern arbeiten, so dass joe@10.0.* den Zugriff von jedem System im Netzwerkbereich 10.0.0.0 aus erlaubt.

Die Seite ssh_config(5)) liefert weitere Einzelheiten darüber, welche Muster zulässig sind.

Schließlich sollte man die folgende Einstellung vornehmen, wenn keine PAM-basierte Authentifizierung benötigt wird:

UsePAM no

Die Funktion sollte nur aktiviert werden, wenn man eine PAM-basierte Authentifizierung benötigt, die sshd nicht von sich aus anbietet. Das ist zum Beispiel erforderlich, wenn ein Benutzerkonto per LDAP (und daher pam_ldap) authentifiziert wird. Ohne UsePAM zu aktivieren, könnte sich der Benutzer niemals einloggen.

Sobald allerdings UsePAM aktiviert ist, funktionieren andere Optionen nicht wie erwartet. So wird PermitRootLogin without-password nicht ordnungsgemäß arbeiten. Wenn kein gültiger ssh-Schlüssel bereitgestellt wird, greift das System auf PAM-basierte Authentifizierung zurück und präsentiert eine Eingabeaufforderung, die nach dem Passwort für den Root-Benutzer fragt.

Mithilfe der einfachen Option AllowUsers dürften also bereits die meisten gewaltsamen Angriffe abgewehrt sein. Denn der Angreifer muss nicht nur das korrekte Passwort erraten, sondern auch das richtige Konto. Alle Versuche, sich mit einem Benutzernamen einzuloggen, der nicht in der Liste der zulässigen Benutzer aufgeführt ist, schlagen dann fehl, auch wenn das korrekte Passwort eingegeben wird.