☰

SELinux verhindert SSH über öffentlichen Schlüssel

tag-icon • tag-icon ssh centos selinux
SELinux verhindert SSH über öffentlichen Schlüssel

Ich habe einen Benutzer $USER, der ein Systembenutzerkonto mit einer autorisierten Benutzerdatei ist. Wenn ich SELinux aktiviert habe, kann ich mich mit dem öffentlichen Schlüssel nicht per SSH beim Server anmelden. Wenn ich setenabled 0, $USERkann ich mich jetzt anmelden.

Welchen SELinux-Bool/welche SELinux-Richtlinie sollte ich ändern, um dieses Verhalten zu korrigieren, ohne SELinux vollständig zu deaktivieren?

Es ist erwähnenswert, dass $USERman sich unter dieser SELinux-Standardkonfiguration mit einem Passwort anmelden kann. Ich wäre für eine Erklärung dankbar, was hier passiert und warum SELinux das nicht blockiert. (Ich werde die Passwortauthentifizierung vollständig deaktivieren, nachdem das Problem gelöst ist, daher ist diese Frage interessanter zu wissen.)

Antwort1

Angenommen, die Dateisystemberechtigungen für ~/.ssh/* sind korrekt, überprüfen Sie die Ausgabe von

sealert -a /var/log/audit/audit.log

Dort sollte ein Hinweis in einem AVC-Eintrag zu finden sein. Höchstwahrscheinlich läuft die Lösung darauf hinaus, Folgendes auszuführen:

restorecon -R -v ~/.ssh

Antwort2

Wenn sealertauf einem System Folgendes fehlt, wie es bei einem System der Fall war, das ich kürzlich gesehen habe, besteht auch die Möglichkeit von audit2allow:

$ sudo audit2allow -w -a
type=AVC msg=audit(1548909218.552:1037): avc:  denied  { read } for  pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

Aufschlüsselung des AVC:

avc: denied { read } for pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556
    "sshd" was denied read on a file resource named "authorized_keys".
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
    SELinux context of the sshd process that attempted the denied action.
tcontext=system_u:object_r:admin_home_t:s0 tclass=file
    SELinux context of the authorized_keys file.

Obwohl audit2allow nicht präzise erklärte, wie das Problem zu beheben ist, zeigt der Wert bei einem Blick auf scontextund den benötigten Kontext an, während der unbefriedigende Dateikontext „authorized_keys“ angezeigt wird.tcontextscontexttcontext

In diesem Fall restorecon -R -v ~/.sshhat es allein nicht funktioniert, aber die Anwendung des gewünschten Kontexts hat funktioniert:

$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh

Ändern Sie bei Bedarf Ressourcennamen und/oder Kontext basierend auf dem, was im AVC angezeigt wird. Die genauen Details in dieser Antwort wurden erstellt, um ein Problem im Zusammenhang mit „authorized_keys“ zu lösen. Eine Lösung könnte jedoch diesem Modell folgen, auch wenn im von sealertoder erstellten AVC eine andere Datei oder ein anderer Kontext angegeben ist audit2allow.

verwandte Informationen