Стежити На Debian і Ubuntu sshd записує у /var/log/auth.log. На RHEL, Rocky, Alma та CentOS Stream він записує у /var/log/secure. Якщо жоден з файлів не існує, ваша система логує лише у журнал systemd. Тоді потрібна вам команда – journalctl -u ssh на системах, що базуються на Debian, або journalctl -u sshd на сімействі Red Hat, Fedora та Arch.
SSH – це «вхідні двері» майже кожного Linux-сервера, тому його журнали з’являються майже в кожному розслідуванні на Linux. Prime Core має 11 632 правила sigma, які працюють на журналах аутентифікації Linux, подібних до цих, пов’язаних із 643 техніками MITRE ATT&CK. Серед них: брутфорс (T1110), входи з використанням вкрадених облікових даних (T1078) та латеральний рух через SSH (T1021.004). Нижче показано, як знайти ваші журнали sshd, експортувати їх, очистити та розслідувати безкоштовно в LogTotal.
Коротко
| Сімейство дистрибутива | Файл журналу | Команда журналу |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, мінімальні установки без rsyslog | відсутній за замовчуванням | journalctl -u sshd |
Перед початком: чи можете ви їх читати?
Журнали аутентифікації спеціально заблоковані, тому звичайний обліковий запис зазвичай не отримує нічого у відповідь.
- /var/log/auth.log на Debian та Ubuntu доступний для читання кореневим користувачем та групою adm.
- /var/log/secure у сімействі Red Hat лише для кореневого користувача.
- Системний журнал відкритий для кореневого користувача та членів systemd-journal, adm і wheel. Всі інші бачать лише свій власний журнал користувача. Якщо ви запускаєте journalctl -u ssh як звичайний користувач, ви отримуєте порожній результат і натяк, що ви не бачите повідомлення від інших користувачів. Це питання дозволів, а не тихий сервер.
Просте вирішення – sudo. Якщо ви налаштовуєте обліковий запис лише для збору журналів, додайте його до adm або systemd-journal замість надання кореневого доступу. Наш [посібник з дозволами журналів Linux] охоплює деталі.
Ще один момент, перш ніж копіювати щось з сервера: журнали аутентифікації містять імена користувачів, IP-адреси джерел та імена хостів. LogTotal очищає завантаження, але спочатку перевірте вашу політику обробки даних.
Крок 1: Файл, журнал або обидва?
Таблиця вище показує налаштування за замовчуванням, і саме їх люблять змінювати образи хмари та скрипти для захисту. Приділіть десять секунд перевірці:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Якщо файл з’являється і rsyslog активний, у вас є обидва: rsyslog копіює повідомлення з журналу в звичайний текстовий файл. Будь-яке джерело підходить, і файл простіше переносити.
Якщо немає файлу, rsyslog просто не встановлений. Це тепер норма: з версії Debian 12 rsyslog більше не входить до складу базової установки, тому на свіжій коробці Debian немає auth.log взагалі. Fedora та Arch так працюють вже роками. Перейдіть до Кроку 2b.
Поки ви тут, перевірте, чи зберігається журнал після перезавантаження:
ls -d /var/log/journal
Якщо цей каталог не існує, journald зберігає журнали в пам’яті у /run/log/journal, і перезавантаження стирає їх. На машині, яку ви розслідуєте, це варто знати, перш ніж хтось вирішить «просто перезапустити її».
Ще один момент для роботи з інцидентами: якщо коробка може бути скомпрометована, її локальні журнали можуть бути теж. Очищення або редагування auth.log – це класичний крок очищення. Якщо сервер пересилає журнали в SIEM, експортуйте звідти також і порівнюйте. Наш [посібник з експорту для Splunk] показує як.
Крок 2a: Експорт з auth.log або secure
Поточний файл покриває лише останні кілька днів. Старіші записи зберігаються в обернених файлах поруч з ним. На Debian і Ubuntu вони виглядають як auth.log.1, auth.log.2.gz і так далі. У сімействі Red Hat вони містять дату, як secure-20261012. Якщо інцидент почався минулого тижня, вам потрібні і ці.
Це витягує лінії sshd з поточного та обернених файлів, від найстаріших до одного файлу:
# Debian / Ubuntu
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/auth.log*) > web-03_sshd.log
# RHEL / Rocky / Alma
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/secure*) > web-03_sshd.log
zgrep читає звичайні та стиснені файли, тому вам не потрібно нічого розпаковувати. ls -tr сортує за часом зміни, тому найстаріший файл йде першим, і вихід залишається приблизно хронологічним. Зразок sshd також відповідає sshd-session, що має значення на новіших системах (див. Крок 2b).
Чому фільтрувати взагалі? Крім зменшення шуму, auth.log також записує sudo, і рядки sudo включають повні командні рядки. Іноді люди випадково вводять паролі туди. Фільтрація для sshd утримує це поза файлом. Винятком є ситуації, коли ви розслідуєте, що зробив зловмисник після входу в систему. Тоді вам потрібні і рядки sudo: беріть увесь файл і дозвольте кроку очищення LogTotal виконати свою роботу.
Швидка перевірка перед завантаженням:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Подивіться на часові позначки. Залежно від конфігурації rsyslog, вони можуть бути класичними syslog (19 жовтня 10:15:01, без року, без часової зони) або повними ISO 8601. Якщо вони класичні, запишіть часову зону сервера (timedatectl). Ви потребуватимете її в момент, коли спробуєте зіставити ці події з чимось іншим.
Крок 2b: Експорт з системного журналу systemd
На системах тільки з журналом, це вся робота:
sudo journalctl -u ssh -u sshd
–since “2026-10-19 00:00” –until “2026-10-20 00:00”
–no-pager -o short-iso > web-03_sshd.log
Декілька рішень у цьому виборі зроблені навмисно.
Обидві назви юнітів. Послуга називається ssh на Debian і Ubuntu, і sshd майже скрізь. journalctl об’єднує повторювані -u прапори з OR, тому одна команда працює на обох сімействах.
Фільтрувати за юнітом, а не за тегом. Багато старих посібників використовують journalctl -t sshd. З версії OpenSSH 9.8 сервер розділений на два двійкових файли, і повідомлення за з’єднанням, включаючи входи, позначені як sshd-session замість sshd. Фільтрація за тегом призводить до втрати саме тих рядків, за якими ви прийшли. Це порушило безліч налаштувань fail2ban і sshguard, коли 9.8 з’явився в 2024 році. RHEL 10 та інші поточні випуски поставляються з OpenSSH 9.8 або новішим. Фільтрування за юнітом охоплює кожен процес, що належить до послуги, як би він не називався.
-o short-iso. Це дає вам рядок у стиль syslog з повною часовою позначкою ISO 8601, включаючи рік і часову зону, тому вам не потрібно вгадувати. Якщо ви бажаєте зберегти кожне поле журналу (PID, boot ID, hostname тощо), використовуйте -o json, який записує по одному JSON об’єкту на рядок. Файл стає більшим, але нічого не втрачається.
Фільтри часу також приймають відносні значення: –since “2 hours ago” або –since yesterday. З постійним журналом, -b -1 обмежує вихід попередньою завантаженням, що допомагає, якщо сервер був перезавантажений після інциденту.
Не копіюйте двійкові .journal файли з /var/log/journal і не завантажуйте їх. LogTotal читає текст і JSON, а файли журналу – ні те, ні інше.
Що шукати, коли у вас є файл
Більшість рядків sshd підпадає під кілька шаблонів:
| Рядок починається з | Що це означає |
|---|---|
| Невірний пароль для <user> від <ip> | Неправильний пароль для облікового запису, що існує |
| Недійсний користувач <user> від <ip> | Ім’я користувача не існує; типовий для сканерів, що перебирають admin, test, oracle |
| Прийнято пароль / Прийнято публічний ключ для | Успішний вхід; рядок з публічним ключем також несе SHA256 відбиток ключа |
| Відключення аутентифікації користувача… Надто багато невдалих спроб аутентифікації | Клієнт досяг MaxAuthTries |
| З’єднання закрито <ip>… [preauth] | Відключено до аутентифікації, зазвичай сканери та читачі банерів |
| pam_unix(sshd:session): відкрито сесію для користувача | Сесія дійсно почалася |
Послідовність варто зупинитися: ряд невдач Failed або Invalid user від одного IP, потім Accepted від того ж IP. Це вдала спроба брутфорса. Трохи позаду: Accepted для облікового запису служби, з адреси, яку ніхто не впізнає, в години, коли ніхто не працює.
У OpenSSH 9.8 і новіших ви також можете побачити повідомлення про покарання: sshd тепер тимчасово відхиляє адреси, які постійно не проходять аутентифікацію. Розглядайте їх як симптом. Вони сигналізують, що хтось активно шукає можливості увійти, а не те, що хтось вже увійшов.
Завантаження, очищення та перегляд у LogTotal
Перегляд кількох сотень рядків оком – нормально. Перегляд 40 000 – ні. LogTotal – це безкоштовний сервіс SOC Prime для запуску логіки виявлення проти файлу журналу без будь-яких налаштувань. Він очищує те, що ви завантажуєте, і не зберігає ваші файли.
- Завантаження. Відкрити logtotal.com і перетягніть туди web-03_sshd.log.
- Очищення. Перегляньте результат перед тим, як продовжити. Ви знаєте, які з тих імен є чутливими у вашому середовищі.
- Перегляд.
Коли це йде не так
| Симптом | Ймовірна причина | Fix |
|---|---|---|
| Файл або каталог auth.log не знайдено | rsyslog не встановлений (за замовчуванням з Debian 12) | Використовуйте journalctl, Крок 2b |
| Доступ заборонений до файлу журналу | auth.log доступний тільки для adm, secure – тільки для root | sudo, або додайте обліковий запис до adm |
| journalctl -u ssh повертає нічого, з натяком на інші облікові записи | Ви не маєте доступу до systemd-journal, adm або wheel | sudo, або додайте обліковий запис до systemd-journal |
| journalctl -u ssh повертає нічого як root | Неправильна назва юніту для цього дистрибутива | Використовуйте -u ssh -u sshd |
| Виходи є, але рядки Accepted відсутні | Фільтрація за тегом (-t sshd) на OpenSSH 9.8+ | Фільтруйте за юнітом натомість |
| Нічого старшого за останнє перезавантаження | Летючий журнал; немає /var/log/journal | Старі журнали зникли; перевірте ваш SIEM або форвардер журналів |
| Файл покриває лише кілька днів | Обернені файли не включені | Використовуйте команду zgrep з auth.log* або secure* |
| Часові позначки не співпадають з іншими джерелами | Класичні часові позначки syslog не містять часової зони | Запишіть часову зону сервера або експортуйте з -o short-iso |
FAQ
Де знаходяться журнали SSH на Ubuntu?
На стандартній установці Ubuntu, у /var/log/auth.log, плюс журнал (journalctl -u ssh). Мінімальні образи хмар іноді не включають rsyslog. Якщо файл відсутній, використовуйте журнал.
Як можна побачити лише невдалі входи SSH?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ на системах з журналом, або sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* коли у вас є файл. Для чого завгодно більшого ніж швидкий перегляд, завантажте повний журнал sshd натомість. Невдачі означають щось лише поряд з успіхами.
Що з last і lastb?
Вони читают двійкові записи входу у /var/log/wtmp і /var/log/btmp. Вони зручні для швидкого погляду, хто заходив, але містять набагато менше деталей, ніж власний журнал sshd, і їх так само легко змінити зловмиснику.
Як зібрати журнали sshd з кількох серверів одночасно?
Для одноразового, цикл це зробить: for h in web-01 web-02 web-03; do ssh “$h” “sudo journalctl -u ssh -u sshd –since yesterday -o short-iso –no-pager” > “${h}_sshd.log” done Це вимагає, щоб sudo працював без запиту паролю з віддаленої сторони. Інакше додайте -t до ssh і вводьте його кожного разу. Якщо ви робите це частіше ніж раз на квартал, відправляйте журнали у SIEM натомість.
Чи безпечно завантажувати журнали sshd в онлайн-інструмент?
LogTotal очищає завантаження перед аналізом і не зберігає файли; наш [посібник з очищення] показує, що маскується. Правила обробки даних вашої організації все ще на першому місці.
Наступний крок
Отримали файл? Завантажте його на LogTotal і подивіться, що роблять з ним ті 11 632 правила sigma. Якщо ви хочете, щоб та ж логіка виявлення працювала на всіх ваших Linux-серверах, а не один файл за раз.
Посилання
- Примітки до випуску Debian 12: зміни в системі логування
- Примітки до випуску OpenSSH 9.8: поділ sshd / sshd-session і зміна тегів журналу
- journalctl(1): фільтри юнітів, формати виходу, групи доступу до журналу
- journald.conf(5): постійне та летюче зберігання
