Стежити На 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.
Спробуйте 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 доступний для root і групи adm.
- /var/log/secure для родини Red Hat доступний тільки для root.
- Системний журнал доступний для root і членів групи systemd-journal, adm і wheel. Усі інші бачать тільки власний користувацький журнал. Якщо ви запускаєте journalctl -u ssh як звичайний користувач, ви отримаєте порожній результат і натяк на те, що ви не бачите повідомлень від інших користувачів. Це пов’язано з правами доступу, а не з тихим сервером.
Простою виправкою є sudo. Якщо ви налаштовуєте акаунт тільки для збирання журналів, додайте його до adm або systemd-journal замість надання прав root. Наш [посібник з дозволів на журнали 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 читає прості та gzip-файли однаково, тому вам не потрібно розпаковувати нічого. 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 (Oct 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 тимчасовою міткою, роком та часового пояса включно, тож вам не потрібно здогадуватись. [ПІДТВЕРДИТИ: LogTotal обробляє short-iso; якщо ні, використовуйте за замовчуванням -o short]. Якщо хочете зберегти кожне поле журналу (PID, boot ID, ім’я хосту тощо), використовуйте -o json, який записує один об’єкт JSON на рядок. Файл стає більшим, але нічого не втрачається.
Часові фільтри також приймають відносні значення: –since “2 години тому” або –since вчора. З постійним журналом -b -1 обмежує вивід до попередньої завантаження, що допомагає, якщо сервер був перезавантажений після інциденту.
Не копіюйте двійкові .journal файли з /var/log/journal і не завантажуйте їх. LogTotal читає текст і JSON, а журнали таким не є.
Що шукати, коли у вас є файл
Більшість рядків sshd підпорядковуються кільком шаблонам:
| Рядок починається з | Що це означає |
|---|---|
| Невірний пароль для <user> з <ip> | Неправильний пароль для існуючого акаунту |
| Невірний користувач <user> з <ip> | Ім’я користувача не існує; типово для сканерів, що прокручують admin, test, oracle |
| Accepted password for / Accepted publickey for | Успішний вхід; рядок publickey також має відбиток SHA256 ключа |
| Disconnecting authenticating user … Too many authentication failures | Клієнт досяг MaxAuthTries |
| Connection closed by <ip> … [preauth] | Відкинуто до автентифікації, зазвичай сканери та грабери банерів |
| pam_unix(sshd:session): session opened for user | Сеанс фактично розпочато |
Послідовність, на яку вартує звернути увагу: серія рядків Failed або Invalid user з одного IP, потім Accepted з того ж IP. Це брутфорс, що спрацював. Закривати за ним: Accepted для сервісного акаунту з адреси, яку ніхто не знає, в час, коли ніхто не працює.
На OpenSSH 9.8 і вище також можуть бути повідомлення про покарання: sshd тепер тимчасово відмовляє адресам, які неодноразово не проходили автентифікацію. Сприймайте їх як симптом. Вони повідомляють вам, що хтось тарабанив по порту, не те що хтось проник.
Завантажте, очищте та перегляньте в LogTotal
Прочитати кілька сотень рядків від руки нормально. Прочитати 40,000 — ні. LogTotal — це безкоштовний сервіс SOC Prime, який дозволяє запускати логіку виявлення проти файлу журналу без налаштування щось ще. Він очищує ваші завантаження та не зберігає файли.
- Завантажте. Відкрийте logtotal.com і завантажте файл web-03_sshd.log. [ПІДТВЕРДИТИ: екран завантаження, обмеження розміру]
- Очищення. [PROOF: what gets masked in an sshd log: usernames, source IPs, hostnames]. Look over the result before you go on. You know which of those names are sensitive in your environment.
- Перегляд. [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
Як це виглядає на реальних даних. Ми згенерували журнали sshd на тестовій віртуальній машині: [ПІДТВЕРДИТИ: що було імітовано, наприклад, запуск випробувань паролів SSH на кількох загальних користувачах, що закінчився одним успішним логіном]. Файл вийшов [ПІДТВЕРДИТИ: N рядків, X KB]. LogTotal зазначив [ПІДТВЕРДИТИ: фактичні знаходження, відповідні правила, техніки ATT&CK].
Хочете спробувати це перед тим, як торкатися власних серверів? [ПІДТВЕРДИТИ: посилання на зразковий файл] — це той самий файл, який ми використовували вище.
Коли щось іде не так
| Симптом | Ймовірна причина | 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): постійне чи летюче зберігання
