Ich habe ein System von einem ausgeschiedenen Kollegen geerbt. Er hat auf dem System eine Zwei-Faktor-Authentifizierung eingerichtet, mit Ausnahme von Benutzer root
und ftpupload
.
Es gibt jedoch einen bestimmten Benutzer, der SSH-Zugriff hat, aber keine Zwei-Faktor-Authentifizierung benötigt. Dieser Benutzer kann sich einfach mit Benutzername und Passwort anmelden!
Mir ist aufgefallen, dass alle Benutzer in der Gruppe disable2fa
eine Zwei-Faktor-Authentifizierung benötigen. Ich sehe in dieser Gruppe nur die folgenden Benutzer:
$ getent group disable2fa
disable2fa:x:2003:root,publicftpupload
Ich habe die PAM-Datei ( sudo nano /etc/pam.d/sshd
) überprüft und sehe Folgendes:
# PAM configuration for the Secure Shell service
# Standard Un*x authentication.
@include common-auth
# Disallow non-root logins when /etc/nologin exists.
account required pam_nologin.so
# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account required pam_access.so
# Standard Un*x authorization.
@include common-account
# SELinux needs to be the first session rule. This ensures that any
# lingering context has been cleared. Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
# Set the loginuid process attribute.
session required pam_loginuid.so
# Create a new session keyring.
session optional pam_keyinit.so force revoke
# Standard Un*x session setup and teardown.
@include common-session
# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
# Print the status of the user's mailbox upon successful login.
session optional pam_mail.so standard noenv # [1]
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session required pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context. Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
# Standard Un*x password updating.
@include common-password
auth [success=done default=ignore] pam_succeed_if.so user ingroup disable2fa
auth required pam_google_authenticator.so nullok
Gibt es noch andere Orte, die ich überprüfen muss? Kann mir jemand helfen? Danke!
Antwort1
Das ist, was diese Zeile bewirkt:
auth [success=done default=ignore] pam_succeed_if.so user ingroup disable2fa
Ausman pam.d
:
ok
this tells PAM that the administrator thinks this return code should contribute
directly to the return code of the full stack of modules. In other words, if the
former state of the stack would lead to a return of PAM_SUCCESS, the module's return
code will override this value. Note, if the former state of the stack holds some value
that is indicative of a modules failure, this 'ok' value will not be used to override
that value.
done
equivalent to ok with the side effect of terminating the module stack and PAM
immediately returning to the application.
Bedeutet im Wesentlichen success=done
, dass, wenn dieses Modul erfolgreich ist, nichts weiter geprüft werden muss, sodass das Nachfolgende pam_google_authenticator.so
übersprungen wird, wenn dieses Modul erfolgreich ist, und dieses Modul prüft nur, obder Benutzer ist die Gruppedisable2fa
:
user ingroup group
User is in given group.
Antwort2
Sie können wahrscheinlich die Zeilen „user ingroup disable2fa“ in Ihren PAM-Konfigurationsdateien dekonfigurieren und durch das Setup ersetzen, das hier dokumentiert ist:
Auf diese Weise werden nur die Benutzer, die ihre Google Authenticator-Tokens konfiguriert haben (Datei ~/.google_authenticator), nach einem Bestätigungscode gefragt. Die Einrichtung der „Benutzergruppe“ war für mich ein Fragezeichen, bis ich das Nullok-Argument in der Dokumentation fand.
Es wirkt wie ein Zauber!