Пользовательское создание удаленный вход
Я пытаюсь централизовать журналы с другого сервера на один сервер.
Я могу централизовать регистрирующуюся информацию через добавление auth.* @server_ip:port в /etc/rsyslog.conf от клиентов, но теперь я не получаю пользовательскую информацию о входе создания. Однако эти журналы находятся в /var/log/auth.log.
Пример:
Jun 1 09:46:20 host sshd[12867]: Accepted password for adminelk from 10.0.0.2 port 63676 ssh2
Jun 1 09:46:20 host sshd[12867]: pam_unix(sshd:session): session opened for user adminelk by (uid=0)
Jun 1 09:46:26 host su[12879]: Successful su for root by adminelk
Jun 1 09:46:26 host su[12879]: + /dev/pts/0 adminelk:root
Jun 1 09:46:26 host su[12879]: pam_unix(su:session): session opened for user root by adminelk(uid=1000)
Jun 1 10:17:01 host CRON[12951]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 1 10:17:01 host CRON[12951]: pam_unix(cron:session): session closed for user root
Jun 1 10:17:01 host groupadd[12955]: group added to /etc/group: name=johnny, GID=1002
Jun 1 10:17:01 host groupadd[12955]: group added to /etc/gshadow: name=johnny
Jun 1 10:17:01 host groupadd[12955]: new group: name=johnny, GID=1002
Jun 1 10:17:01 host useradd[12959]: new user: name=johnny, UID=1004, GID=1002, home=/home/johnny, shell=/bin/bash
Jun 1 10:17:05 host passwd[12966]: pam_unix(passwd:chauthtok): password changed for johnny
Jun 1 10:17:08 host chfn[12967]: changed user 'johnny' information
Я могу получить журналы sshd, но не useradd журналы...
Как я мог получить эти журналы?
1 ответ
TL; DR
Использовать auth,authpriv.* @server_ip:port
Подробности
Вы используете неправильное средство, соответственно. не все правильные средства.
Чтобы проанализировать поведение, я запустил
journalctl -o verbose -t useradd -t groupadd -t passwd -f
в одном окне и сделал
adduser foo
в другом (оба как root).
journald перехватывает (локальные) сообщения системного журнала, которые можно просмотреть с помощью journalctl. Последний допускает различные выходные форматы, один из которых является подробным со всеми полями сообщений системного журнала .
Вывод был примерно таким:
Wed 2018-06-06 21:05:22.618392 CEST [...]
...
PRIORITY=6
SYSLOG_FACILITY=10
...
SYSLOG_IDENTIFIER=groupadd
...
MESSAGE=group added to /etc/group: name=foo, GID=1004
Wed 2018-06-06 21:05:22.630643 CEST [...]
...
PRIORITY=6
SYSLOG_FACILITY=10
...
SYSLOG_IDENTIFIER=groupadd
...
MESSAGE=group added to /etc/gshadow: name=foo
...
Wed 2018-06-06 21:05:22.631667 CEST [...]
...
PRIORITY=6
SYSLOG_FACILITY=10
...
SYSLOG_IDENTIFIER=groupadd
...
MESSAGE=new group: name=foo, GID=1004
...
Wed 2018-06-06 21:05:22.635070 CEST [...]
...
PRIORITY=6
SYSLOG_FACILITY=10
...
SYSLOG_IDENTIFIER=useradd
...
MESSAGE=new user: name=foo, UID=1002, GID=1004, home=/home/foo, shell=/bin/bash
...
Wed 2018-06-06 21:05:22.699151 CEST [...]
PRIORITY=4
...
SYSLOG_FACILITY=10
...
SYSLOG_IDENTIFIER=passwd
MESSAGE=pam_ecryptfs: PAM passphrase change module retrieved a NULL passphrase; nothing to do
...
Как мы можем видеть здесь, SYSLOG_FACILITY является 10 для всех этих сообщений. Это не auth, а authpriv .
Фактически, моя конфигурация rsyslog содержит строку
auth,authpriv.* /var/log/auth.log
в файле /etc/rsyslog.d/50-default.conf.
Поэтому я предлагаю использовать
auth,authpriv.* @server_ip:port
не только для пересылки auth сообщений, но также authpriv сообщений.