☰

Разрешить вход по паролю SSH в локальной сети

tag-icon • tag-icon linux ssh selinux
Разрешить вход по паролю SSH в локальной сети

У меня есть домашний сервер под управлением Fedora 16, к которому я хотел бы иметь удаленный доступ через SSH. Пользователям с доступом sudo должно быть разрешено подключаться из WAN только с ключом, но я хочу разрешить им подключаться из локальной сети с паролем.

Вот мой 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

Самое интересное, что это работает отлично, когда я запускаю sshd -d -p 4000его в режиме отладки и тестирую, но попытка войти в систему с паролем, когда я запускаю sshd через systemctl, терпит неудачу.

Как и большинство проблем при настройке этой машины, я считаю, что виновником является SELinux. Вот сообщение об ошибке из журнала аудита.

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'

Если я временно отключу SELinux, то это сработает. Если я использую audit2why для этого сообщения, то ничего не выводится. Если я пытаюсь использовать audit2allow для этого сообщения, то выводится 3 новых строки, но ничего больше. Возможно, я неправильно его использую, но вот что я сделал:

$ tail -n 1 /var/log/audit/audit.log > error.txt
$ audit2why -i error.txt
$ audit2allow -i error.txt


$

Кто-нибудь сталкивался с этим раньше? Стоит ли вообще оставлять SELinux включенным?

Связанный контент