Śledź Na Debianie i Ubuntu sshd zapisuje do /var/log/auth.log. Na RHEL, Rocky, Alma i CentOS Stream zapisuje do /var/log/secure. Jeśli żaden z tych plików nie istnieje, system loguje tylko do dziennika systemd. Wtedy polecenie, którego potrzebujesz, to journalctl -u ssh na systemach opartych na Debianie, lub journalctl -u sshd na rodzinie Red Hat, Fedora i Arch.
SSH jest frontowymi drzwiami prawie każdego serwera Linux, dlatego jego logi pojawiają się w prawie każdym dochodzeniu w systemie Linux. Prime Core ma 11 632 reguły sigma, które działają na takich logach uwierzytelniania Linuxa, zmapowane do 643 technik MITRE ATT&CK. Wśród nich: atak brute force (T1110), logowania z użyciem skradzionych poświadczeń (T1078) i ruch lateralny przez SSH (T1021.004). Oto, jak znaleźć swoje logi sshd, eksportować je, oczyszczać i badać za darmo w LogTotal.
TL;DR
| Rodzina dystrybucji | Plik logu | Polecenie dziennika |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, minimalne instalacje bez rsyslog | brak domyślnie | journalctl -u sshd |
Zanim zaczniesz: czy możesz je w ogóle przeczytać?
Logi uwierzytelniania są celowo zablokowane, więc regularne konto zazwyczaj nic nie zwraca.
- /var/log/auth.log na Debian i Ubuntu jest czytelny dla root i grupy adm.
- /var/log/secure na rodzinie Red Hat jest tylko dla root.
- Dziennik systemowy jest otwarty dla root i członków systemd-journal, adm i wheel. Wszyscy inni widzą tylko swój własny dziennik użytkownika. Jeśli uruchomisz journalctl -u ssh jako zwykły użytkownik, uzyskasz pusty wynik i podpowiedź, że nie widzisz wiadomości od innych użytkowników. To kwestia uprawnień, a nie cichego serwera.
Prostym rozwiązaniem jest sudo. Jeśli tworzysz konto tylko do zbierania logów, dodaj je do adm lub systemd-journal zamiast rozdawać prawa roota. Nasz [przewodnik po uprawnieniach w logach Linuxa] zawiera szczegóły.
Jeszcze jedna rzecz zanim skopiujesz cokolwiek z serwera: logi auth zawierają nazwy użytkowników, źródłowe IP i nazwy hostów. LogTotal oczyszcza przesłane pliki, ale najpierw sprawdź swoją politykę przetwarzania danych.
Krok 1: Plik, dziennik, czy oba?
Tabela powyżej pokazuje domyślne ustawienia, a domyślne ustawienia to dokładnie to, co lubią zmieniać obrazy w chmurze i skrypty utwardzania. Poświęć dziesięć sekund, aby sprawdzić:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Jeśli plik się pojawi i rsyslog jest aktywny, masz oba: rsyslog kopiuje wiadomości z dziennika do pliku tekstowego. Dowolne źródło działa, a plik jest łatwiejszy do kopiowania.
Jeśli nie ma pliku, po prostu rsyslog nie jest zainstalowany. To teraz norma: od Debian 12 rsyslog nie jest już częścią domyślnej instalacji, więc świeża skrzynka Debian nie ma w ogóle auth.log. Fedora i Arch działają w ten sposób od lat. Przejdź do kroku 2b.
Skoro już tu jesteś, sprawdź, czy dziennik przetrwa restart:
ls -d /var/log/journal
Jeśli ten katalog nie istnieje, journald przechowuje logi w pamięci pod /run/log/journal, a po ponownym uruchomieniu zostają wyczyszczone. Na maszynie, którą badacie, warto to wiedzieć, zanim ktoś zdecyduje się na „po prostu restart”.
Jeszcze jedna uwaga do pracy incydentalnej: jeśli maszyna może być zagrożona, lokalne logi również mogą być. Usuwanie lub edytowanie auth.log to klasyczny krok czyszczenia. Jeśli serwer przekazuje logi do SIEM, również je eksportuj i porównaj. Nasz [przewodnik eksportowy Splunk] pokazuje, jak to zrobić.
Krok 2a: Eksport z auth.log lub secure
Bieżący plik obejmuje tylko ostatnie kilka dni. Starsze wpisy znajdują się w plikach obrotowych obok niego. Na Debianie i Ubuntu wyglądają jak auth.log.1, auth.log.2.gz i tak dalej. Na rodzinie Red Hat mają datę, jak secure-20261012. Jeśli incydent rozpoczął się w zeszłym tygodniu, potrzebujesz także tych.
Powyższy przykład wyciąga linie sshd z bieżących i obrotowych plików, od najstarszego do jednego pliku:
# 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 przetwarza zarówno pliki tekstowe, jak i kompresowane gzipem, więc nie musisz niczego rozpakowywać. ls -tr sortuje według czasu modyfikacji, więc najstarszy plik idzie pierwszy, a wynik pozostaje mniej więcej chronologiczny. Wzorzec sshd pasuje również do sshd-session, co ma znaczenie w nowszych systemach (patrz krok 2b).
Dlaczego filtrować w ogóle? Oprócz redukcji hałasu, auth.log zapisuje także sudo, a linie sudo zawierają pełne linie poleceń. Ludzie czasami wpisują w nich hasła. Filtrowanie do sshd pozwala to wykluczyć. Wyjątkiem jest sytuacja, gdy badamy, co zrobił atakujący po zalogowaniu się. Wtedy chcesz także linie sudo: weź cały plik i pozwól, aby krok oczyszczania w LogTotal zrobił swoje.
Szybka kontrola przed przesłaniem:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Spójrz na znaczniki czasowe. W zależności od konfiguracji rsyslog, mogą to być klasyczne syslog (19 paź 10:15:01, brak roku, brak strefy czasowej) lub pełne ISO 8601. Jeśli są klasyczne, zanotuj strefę czasową serwera (timedatectl). Będziesz tego potrzebował, kiedy spróbujesz zestawić te zdarzenia z czymkolwiek innym.
Krok 2b: Eksport z dziennika systemd
Na systemach tylko z dziennikiem, to cała praca:
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
Kilka wyborów w tamtym poleceniu jest celowych.
Oba nazwy jednostek. Usługa nazywa się ssh na Debianie i Ubuntu oraz sshd prawie wszędzie indziej. journalctl łączy powtarzające się flagi -u za pomocą OR, więc to samo polecenie działa w obu rodzinach.
Filtruj według jednostki, a nie według tagu. Wiele starszych poradników używa journalctl -t sshd. Od OpenSSH 9.8, serwer jest podzielony na dwa pliki wykonywalne, a wiadomości na połączenie, w tym logowania, są oznaczone jako sshd-session zamiast sshd. Filtry według tagu tracą dokładnie te linie, które przyszliśmy. To złamało wiele konfiguracji fail2ban i sshguard, gdy 9.8 zadebiutowała w 2024 roku. RHEL 10 i inne bieżące wydania udostępniają OpenSSH 9.8 lub nowszy. Filtry według jednostki łapią każdy proces należący do usługi, jakkolwiek ją nazwano.
-o short-iso. Daje linię w stylu syslog z pełnym znacznikiem czasu ISO 8601, z włączonym rokiem i strefą czasową, więc nie musisz zgadywać. [DOWÓD: potwierdź, że LogTotal analizuje short-iso; jeśli nie, użyj domyślnego -o short]. Jeśli wolisz zachować każde pole dziennika (PID, ID rozruchu, nazwę hosta itp.), użyj -o json, co generuje jeden obiekt JSON na linię. Plik robi się większy, ale nic nie zostaje pominięte.
Filtry czasu przyjmują również wartości względne: –since „2 godziny temu” lub –since wczoraj. Z persystentnym dziennikiem, -b -1 ogranicza wynik do poprzedniego rozruchu, co pomaga, jeśli serwer został ponownie uruchomiony po incydencie.
Nie kopiuj binarnych plików dziennika .journal z /var/log/journal i nie przesyłaj ich. LogTotal czyta tekst i JSON, a pliki dziennika nie są ani jednym, ani drugim.
Na co zwracać uwagę, gdy już masz plik
Większość linii sshd ostatecznie mieści się w garści wzorców:
| Linia zaczyna się od | Co to znaczy |
|---|---|
| Błędne hasło dla <użytkownik> z <ip> | Błędne hasło dla istniejącego konta |
| Nieprawidłowy użytkownik <użytkownik> z <ip> | Nazwa użytkownika nie istnieje; typowe dla skanerów przeszukujących admin, test, oracle |
| Hasło zaakceptowane dla / Akceptowany klucz publiczny dla | Udane logowanie; linia klucza publicznego zawiera także odcisk SHA256 klucza |
| Rozłączanie użytkownika uwierzytelnienia … Zbyt wiele błędów uwierzytelniania | Klient osiągnął MaxAuthTries |
| Połączenie zamknięte przez <ip> … [preauth] | Przerwane przed uwierzytelnieniem, zwykle skanery i grabery banerów |
| pam_unix(sshd:session): sesja otwarta dla użytkownika | Sesja faktycznie się rozpoczęła |
Sekwencja warta zatrzymania się: seria linii Błędne lub Nieprawidłowy użytkownik z jednego IP, następnie zaakceptowana z tego samego IP. To jest brute force, który działał. Tuż za: zaakceptowana dla konta usługowego, z adresu, którego nikt nie rozpoznaje, o godzinie, o której nikt nie pracuje.
Na OpenSSH 9.8 i nowszych można również zobaczyć komunikaty o karach: sshd tymczasowo odmawia adresom, które ciągle nie przechodzą uwierzytelnienia. Traktuj je jako objaw. Mówią, że ktoś uderzał w port, a nie, że ktokolwiek dostał się do środka.
Przesyłanie, oczyszczanie i przeglądanie w LogTotal
Przeglądanie kilku setek linii gołym okiem jest w porządku. Przeglądanie 40 000 już nie. LogTotal to darmowa usługa SOC Prime do uruchamiania logiki detekcji względem pliku dziennika bez potrzeby jakiejkolwiek konfiguracji. Oczyszcza przesłane dane i nie przechowuje plików.
- Przesyłanie. Odwiedź logtotal.com i wrzuć web-03_sshd.log. [DOWÓD: ekran przesyłania, limit rozmiaru]
- Oczyszczanie. [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.
- Przeglądanie. [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
Jak to wygląda na rzeczywistych danych. Wygenerowaliśmy logi sshd na komputerze testowym: [DOWÓD: co symulowano, np. rutynową próbę ataku na hasło SSH przeciwko kilku powszechnym nazwom użytkownika, zakończoną jednym udanym logowaniem]. Plik wynosił [DOWÓD: N linii, X KB]. LogTotal oznaczył [DOWÓD: rzeczywiste ustalenia, dopasowane reguły, techniki ATT&CK].
Chcesz spróbować tego przed dotknięciem własnych serwerów? [DOWÓD: link do przykładowego pliku] to ten sam plik, którego użyliśmy powyżej.
Kiedy coś idzie źle
| Objaw | Prawdopodobna przyczyna | Fix |
|---|---|---|
| Brak pliku lub katalogu dla auth.log | rsyslog nie jest zainstalowany (domyślny od Debian 12) | Użyj journalctl, krok 2b |
| Brak uprawnień do pliku dziennika | auth.log jest tylko dla adm, secure jest tylko dla root | sudo, lub dodaj konto do adm |
| journalctl -u ssh zwraca nic, z podpowiedzią o innych użytkownikach | Nie jesteś w systemd-journal, adm lub wheel | sudo, lub dodaj konto do systemd-journal |
| journalctl -u ssh zwraca nic jako root | Zła nazwa jednostki dla tej dystrybucji | Użyj -u ssh -u sshd |
| Są wylogowania, ale brak linii zaakceptowanych | Filtrowanie według tagu (-t sshd) na OpenSSH 9.8+ | Filtruj według jednostki zamiast |
| Nic starszego niż ostatni restart | Lotny dziennik; brak /var/log/journal | Stare logi zniknęły; sprawdź swój SIEM lub forwarder logów |
| Plik obejmuje tylko kilka dni | Obrotowe pliki nie zostały uwzględnione | Użyj polecenia zgrep z auth.log* lub secure* |
| Znaczniki czasowe nie pasują do innych źródeł | Klasyczne znaczniki czasu syslog nie mają strefy czasowej | Zanotuj strefę czasową serwera lub eksportuj z -o short-iso |
FAQ
Gdzie są logi SSH na Ubuntu?
Na standardowej instalacji Ubuntu w /var/log/auth.log, plus dziennik (journalctl -u ssh). Minimalne obrazy chmurowe czasami pomijają rsyslog. Jeśli plik nie jest tam, użyj dziennika.
Jak mogę zobaczyć tylko nieudane logowania SSH?
sudo journalctl -u ssh -u sshd | grep -E 'Failed|Invalid user’ na systemach z dziennikiem, lub sudo zgrep -hE 'Failed|Invalid user’ /var/log/auth.log* gdy masz plik. Dla czegokolwiek poza szybkim spojrzeniem, prześlij pełny dziennik sshd zamiast tego. Same niepowodzenia mają znaczenie jedynie w zestawieniu z sukcesami.
Co z last i lastb?
Odczytują binarne rekordy logowania w /var/log/wtmp i /var/log/btmp. Są przydatne do szybkiego przeglądu, kto się zalogował, ale zawierają znacznie mniej szczegółów niż własny dziennik sshd i są równie łatwe do manipulacji przez intruzów.
Jak zbierać logi sshd z kilku serwerów naraz?
Na potrzeby jednorazowego zadania, pętla to załatwia: 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 To wymaga sudo, aby działać bez żądania hasła po stronie zdalnej. W przeciwnym razie, dodaj -t do ssh i wpisuj hasło za każdym razem. Jeśli robisz to częściej niż raz na kwartał, wysyłaj logi do SIEM zamiast.
Czy przesyłanie logów sshd do narzędzia online jest bezpieczne?
LogTotal oczyszcza przesłane dane przed analizą i nie przechowuje plików; nasz [przewodnik po oczyszczaniu] pokazuje, co jest maskowane. Zasady przetwarzania danych Twojej organizacji wciąż są najważniejsze.
Następny krok
Masz już plik? Prześlij go do LogTotal i zobacz, co te 11 632 reguły sigma z niego zrobią. Jeśli chcesz mieć tę samą logikę detekcji działającą na wszystkich swoich serwerów Linux, a nie na jednym pliku naraz.
Bibliografia
- Notatki wydania Debian 12: zmiany w logowaniu systemowym
- Notatki wydania OpenSSH 9.8: podział sshd / sshd-session i zmienione tagi dziennika
- journalctl(1): filtry jednostek, formaty wyjściowe, grupy dostępu do dziennika
- journald.conf(5): trwałe a nietrwałe przechowywanie
