Ich habe einen Heimserver mit Fedora 16, auf den ich per SSH remote zugreifen möchte. Benutzern mit Sudo-Zugriff sollte es nur gestattet sein, sich vom WAN aus mit einem Schlüssel zu verbinden, ich möchte ihnen jedoch erlauben, sich vom lokalen Netzwerk aus mit einem Passwort zu verbinden.
Hier ist meine sshd_config:
#Logging
SyslogFacility AUTHPRIV
#Allow the two types of ssh groups
AllowGroups ssh_key_users ssh_pass_users
PermitRootLogin no
#Accept environment variables - these come from the fedora default config
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
#Other options
X11Forwarding yes
GSSAPICleanupCredentials yes
#Set up sftp subsytem
Subsystem sftp /usr/libexec/openssh/sftp-server
#Just as a default, we'll change it per network and group
PasswordAuthentication no
#Re-enable password access for the local network
Match Address 192.168.1.0/24 Group ssh_key_users
PasswordAuthentication yes
#Settings for users which can login by password (non-sudoers)
Match Group ssh_pass_users
PasswordAuthentication yes
ChrootDirectory %h
Das Lustige daran ist, dass es perfekt funktioniert, wenn ich sshd -d -p 4000es in den Debug-Modus versetze und teste, aber der Versuch, mich mit einem Kennwort anzumelden, wenn ich sshd über systemctl ausführe, schlägt fehl.
Wie bei den meisten Problemen bei der Konfiguration dieser Maschine glaube ich, dass SELinux der Übeltäter ist. Hier ist die Fehlermeldung aus audit.log
type=USER_AUTH msg=audit(1345320824.824:123275):
pid=0 uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
msg='op=password acct="chockey" exe="/usr/sbin/sshd"
hostname=? addr=192.168.1.201 terminal=ssh res=failed'
Wenn ich SELinux vorübergehend ausschalte, funktioniert es. Wenn ich audit2why auf diese Nachricht anwende, gibt es keine Ausgabe. Wenn ich versuche, audit2allow auf diese Nachricht anzuwenden, gibt es 3 Zeilenumbrüche aus, aber sonst nichts. Vielleicht verwende ich es falsch, aber so habe ich es gemacht:
$ tail -n 1 /var/log/audit/audit.log > error.txt
$ audit2why -i error.txt
$ audit2allow -i error.txt
$
Ist das schon mal jemandem passiert? Lohnt es sich überhaupt, SELinux eingeschaltet zu lassen?