/var/log/auth.log не записує невдалі спроби ssh

10

На моєму сервері я не намагаюся (або неправильне ім’я користувача, пароль або обидва).

Я змінив / etc / ssh / sshd_config з

# Logging
SyslogFacility AUTH 
LogLevel INFO

до

# Logging
SyslogFacility AUTH 
LogLevel VERBOSE

і з тих пір пробували кілька спроб ssh як для існуючих, так і для неіснуючих користувачів із випадковими паролями, таким чином, не вдалося. Під час перевірки /var/log/auth.log нічого не з’являється, і воно повністю порожнє.

Що я пропускаю? Чи потрібно також встановити та запустити якийсь інший процес у моїй системі? Я запускаю Ubuntu.

Будь-яка допомога чи настанова з цього приводу є більш ніж вітається.

Дякую

ssh logging authentication

— edev.io
джерело

1

Ви перезапустили sshd?

— бонсайвінг

1

Як виглядає ваша конфігурація syslog? Це, ймовірно, файл у /etc/syslog.confабо /etc/rsyslog.confабо/etc/rsyslog.d/*.conf

— Стефан Ласєвський

@StefanLasiewski перші 2 порожні та /etc/rsyslog.d/*.confкажуть "$ AddUnixListenSocket / var / spool / postfix / dev / log"

— edev.io

@Georgejnr: Якщо це так, виявляється, що конфігурація syslog у вашій системі порушена. Зазвичай файл syslog знаходиться під /etc/syslog.conf або /etc/rsyslog.conf, і зазвичай має бути більше одного файлу під /etc/rsyslog.d/*.conf. Чи ps auxвідображається процес системного журналу?

— Стефан Ласєвський

@StefanLasiewski ні він не вказаний у ps aux. Попередній сисадмін пішов трохи негідником і зламав декілька речей, які я вірю цілеспрямовано. Думаєте, це може бути частиною цього? Як я можу вирішити цю проблему?

— edev.io

6

Зазвичай LogLevel (мабуть, залежить від програми) відноситься до одного з визначених рівнів суворості, підтримуваних процесом системного журналу (syslog). Тому змініть його назад і перезапустіть сервер sshd.

Тепер, якщо ви не отримуєте висновок, вам потрібно подивитися на систему /etc/syslog.conf і побачити, який MINIMUM вирівнювання рівнів запитів AUTH реєструється та в який файл. Помилки можуть бути в іншому файлі журналу. АБО ви можете не записувати ці помилки через конфігурацію syslog.conf для служби AUTH. Для отримання додаткової інформації зверніться до сторінок man на та syslog.conf.

— mdpc
джерело

Від sshd_config (5) LogLevel: задає рівень багатослів’я, який використовується під час реєстрації повідомлень із sshd (8). Можливі значення: QUIET, FATAL, ERROR, INFO, VERBOSE , DEBUG, DEBUG1, DEBUG2 та DEBUG3.

— бонсайвінг

1

мій /syslog.conf порожній. Треба додати, що я переймаю чужу систему і, здається, вони не дуже добре справилися з її налаштуванням. Чи означає відсутність syslog.conf, що я пропускаю послугу? (дякую за вашу відповідь)

— edev.io

Файл знаходиться в /etc...... можливо, ви можете нічого не входити в журнал.

— mdpc

Про VERBOSE в sshd_config .... моя помилка, але це не рівень журналу syslog, який зазвичай запитують у багатьох програмах, з якими я маю справу.

— mdpc

залишаючи VERBOSE все ще в моєму sshd_config і запускаючи sudo /etc/init.d/ssh перезапуск, він все ще не веде журнал. Невже я щось німий?

— edev.io

5

Коли у мене була така ж проблема з Debian, я виявив, що мені доведеться перезапустити rsyslogd:

/etc/init.d/rsyslog restart

(Ваша програма syslogd може відрізнятися.)

Він знову почав писати в /var/log/auth.log.

Можливо, він перестав вести журнал після повної події на диску, я не впевнений.

Дивіться також: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1059854/comments/9

— Сем Уоткінс
джерело

1

Це працювало для мене, але використовуючи systemctl замість цього, щоб перезапустити службу syslog (Debian sid за допомогою inetutils-syslogd). systemctl restart inetutils-syslogd.service

— Брайан Мінтон

3

У моєму випадку в кореневій файловій системі зліва не було дискового простору /, з яким ви можете перевіритиdf -h

— yellowsir
джерело

3

У моєму випадку проблема була у власності на /var/log/auth.logфайл. Він володів, root:rootале повинен бути syslog:adm. Змінити на

sudo chown syslog:adm /var/log/auth.log

Схоже, це проблема із новоствореними системами - було більше файлів журналів, які мали цю проблему.