Śledź Na Debianie i Ubuntu, sshd zapisuje w /var/log/auth.log. Na RHEL, Rocky, Alma i CentOS Stream, zapisuje w /var/log/secure. Jeśli żaden z plików nie istnieje, system zapisuje jedynie do dziennika systemd. Następnie komenda, którą chcesz użyć, to journalctl -u ssh na systemach opartych na Debianie lub journalctl -u sshd na rodzinie Red Hat, Fedora i Arch.
SSH jest wejściem do prawie każdego serwera Linux, dlatego jego logi pojawiają się w prawie każdym dochodzeniu na Linuxie. Prime Core ma 11 632 reguły sigma, które działają na logach uwierzytelniania Linuxa, jak te, mapowane na 643 techniki MITRE ATT&CK. Wśród nich: bruteforce (T1110), logowania z użyciem skradzionych danych uwierzytelniających (T1078) i poruszanie się lateralne przez SSH (T1021.004). Poniżej opisano, jak znaleźć logi sshd, wyeksportować je, zanonimizować i zbadać za darmo w LogTotal.
TL;DR
| Rodzina dystrybucji | Plik logu | Komenda 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 faktycznie je możesz odczytać?
Logi uwierzytelniania są zablokowane celowo, więc zwykle zwykłe konto nic nie zwraca.
- /var/log/auth.log na Debianie i Ubuntu jest czytelny przez root i grupę adm.
- /var/log/secure w rodzinie Red Hat jest dostępny tylko dla root.
- Dziennik systemowy jest dostępny dla root oraz dla członków systemd-journal, adm i wheel. Wszyscy inni widzą tylko swój własny dziennik użytkownika. Jeśli uruchomisz jako zwykły użytkownik journalctl -u ssh, otrzymasz pusty wynik i sugestię, że nie widzisz wiadomości od innych użytkowników. To problem z uprawnieniami, nie cichy serwer.
Proste rozwiązanie to sudo. Jeśli zakładasz konto tylko do zbierania logów, dodaj je do adm lub systemd-journal zamiast przyznawać root. Nasz [Przewodnik po uprawnieniach logów Linuxa] zawiera szczegóły.
Jeszcze jedna rzecz, zanim skopiujesz cokolwiek z serwera: logi autoryzacyjne zawierają nazwy użytkowników, źródłowe IP i nazwy hostów. LogTotal anonimizuje przesłane pliki, ale najpierw sprawdź swoją politykę dotyczącą przetwarzania danych.
Krok 1: Plik, dziennik czy oba?
Tabela powyżej pokazuje domyślne wartości, a domyślne to dokładnie to, co chętnie zmieniają obrazy chmurowe i skrypty utwardzające. Spędź dziesięć sekund na weryfikacji:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Jeśli pojawi się plik i rsyslog jest aktywny, masz oba: rsyslog kopiuje wiadomości z dziennika do pliku w formacie tekstowym. Oba źródła działają, a plik jest łatwiejszy do kopiowania.
Jeśli nie ma pliku, rsyslog po prostu nie jest zainstalowany. To teraz norma: od Debian 12, rsyslog nie jest częścią domyślnej instalacji, więc świeża instalacja Debian nie ma w ogóle auth.log. Fedora i Arch działają w ten sposób od lat. Przejdź do Krok 2b.
Gdy jesteś tutaj, sprawdź, czy dziennik przetrwa restart:
ls -d /var/log/journal
Jeśli ten katalog nie istnieje, journald trzyma logi w pamięci pod /run/log/journal, a restart je kasuje. Na maszynie, którą badajesz, warto to wiedzieć, zanim ktoś zdecyduje się na „po prostu zrestartować”.
Jeszcze jedno dla pracy incydentalnej: jeśli maszyna może być skompromitowana, jej lokalne logi również mogą być. Kasowanie lub edytowanie auth.log to klasyczny krok sprzątający. Jeśli serwer przesyła logi do SIEM, wyeksportuj stamtąd i porównaj. Nasz [Przewodnik eksportu do Splunk] pokazuje jak.
Krok 2a: Eksportuj z auth.log lub secure
Bieżący plik obejmuje tylko ostatnie kilka dni. Starsze wpisy siedzą w plikach zrotowanych obok niego. Na Debianie i Ubuntu wyglądają jak auth.log.1, auth.log.2.gz i tak dalej. Na rodzinie Red Hat są datowane, jak secure-20261012. Jeśli incydent rozpoczął się w zeszłym tygodniu, potrzebujesz także tych.
To ciągnie linie sshd z bieżącego i zrotowanych 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 czyta zarówno pliki tekstowe, jak i gzipowane, więc nie musisz nic wypakowywać. ls -tr sortuje według czasu modyfikacji, więc najstarszy plik jest pierwszy, a wynik pozostaje w przybliżeniu chronologiczny. Szablon sshd pasuje również do sshd-session, co ma znaczenie na nowszych systemach (patrz Krok 2b).
Why filter at all? Oprócz redukcji szumu, auth.log także zapisuje sudo, a linie sudo zawierają pełne linie komend. Ludzie czasem wpisują w nie hasła. Filtracja do sshd utrzymuje to poza plikiem. Wyjątkiem jest, gdy bada się, co napastnik zrobił po zalogowaniu się. Wtedy chcesz również linie sudo: całość pobierz i pozwól, by krok anonimizacji LogTotal wykonał swoje zadanie.
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 stemple czasowe. W zależności od konfiguracji rsyslog, są to klasyczne syslog (19 paź 10:15:01, brak roku, brak strefy czasowej) lub pełny ISO 8601. Jeśli są klasyczne, zanotuj strefę czasową serwera (timedatectl). Będziesz jej potrzebował, kiedy będziesz próbował zgrupować te zdarzenia z czymś innym.
Krok 2b: Eksportuj z dziennika systemd
Na systemach tylko z dziennikiem, to cała robota:
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 tam jest celowe.
Obie nazwy jednostek. Usługa nazywa się ssh na Debianie i Ubuntu oraz sshd prawie wszędzie indziej. journalctl łączy powtarzające się flagi -u razem jako OR, więc ta sama komenda działa na obu rodzinach.
Filtruj według jednostki, a nie tagu. Wiele starszych poradników używa journalctl -t sshd. Od OpenSSH 9.8, serwer jest podzielony na dwa binaria, a wiadomości na połączenie, w tym logowania, są oznaczane sshd-session zamiast sshd. Filtruj według tagu, a stracisz dokładnie te linie, na które przyszedłeś. To złamało wiele ustawień fail2ban i sshguard, kiedy 9.8 zadebiutował w 2024 roku. RHEL 10 i inne bieżące wersje dostarczają OpenSSH 9.8 lub nowsze. Filtracja według jednostki łapie każdy proces należący do usługi, cokolwiek się nazywa.
-o short-iso. Daje Ci linię w stylu syslog z pełnym znacznikiem czasu ISO 8601, z uwzględnieniem roku i strefy czasowej, więc nie musisz zgadywać. Jeśli wolisz zachować każde pole dziennika (PID, boot ID, hostname i tak dalej), użyj -o json, co zapisuje jeden obiekt JSON na linię. Plik robi się większy, ale nic nie zostaje stracone.
Filtry czasu przyjmują również wartości względne: –since „2 hours ago” lub –since yesterday. Z trwałym dziennikiem, -b -1 ogranicza wynik do poprzedniego rozruchu, co jest pomocne, jeśli serwer był restartowany po incydencie.
Nie kopiuj binarnych plików .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 zwrócić uwagę, gdy masz plik
Większość linii sshd wpisuje się w kilka wzorców:
| Linia zaczyna się od | Co to oznacza |
|---|---|
| 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 cyklicznie sprawdzających admin, test, oracle |
| Akceptowane hasło dla / Akceptowany klucz publiczny dla | Udane logowanie; linia z kluczem publicznym również zawiera odcisk palca SHA256 klucza |
| Zakończenie sesji uwierzytelniającej użytkownik… Zbyt wiele nieudanych prób uwierzytelnienia | Klient osiągnął MaxAuthTries |
| Połączenie zamknięte przez <ip>… [przed autoryzacją] | Zrzucone przed uwierzytelnieniem, zwykle skanery i grabberzy banerów |
| pam_unix(sshd:session): sesja otwarta dla użytkownika | Sesja faktycznie się rozpoczęła |
Sekwencja, na którą warto zwrócić uwagę: seria lini Błędne lub Nieprawidłowe użytkownik z jednego IP, a potem Akceptowane z tego samego IP. To pełzanie siłą, które zadziałało. Zza tym: Akceptowane dla konta serwisowego, z adresu, którego nikt nie rozpoznaje, o godzinie, w której nikt nie pracuje.
W OpenSSH 9.8 i późniejszych możesz również zobaczyć wiadomości o karach: sshd teraz tymczasowo odmawia adresów, które ciągle nieudanie uwierzytelniają się. Traktuj je jako symptom. Mówią Ci, że ktoś właśnie szturmował port, a nie że ktoś się dostał.
Przesyłaj, anonimizuj i przeglądaj w LogTotal
Czytanie kilkuset linii na oko jest w porządku. Czytanie 40 000 nie jest. LogTotal to bezpłatna usługa SOC Prime do uruchamiania logiki detekcji na pliku dziennika bez jakichkolwiek konfiguracji. Anonimizuje to, co przesyłasz, i nie przechowuje plików.
- Przesyłaj. Otwórz logtotal.com i upuść web-03_sshd.log.
- Anonimizuj. Przejrzyj wynik, zanim przejdziesz dalej. Wiesz, które z tych nazw są wrażliwe w Twoim środowisku.
- Przeglądaj.
Kiedy coś idzie nie tak
| Symptom | Prawdopodobna przyczyna | Fix |
|---|---|---|
| Nie ma takiego pliku lub katalogu dla auth.log | rsyslog nie jest zainstalowany (domyślnie od Debian 12) | Użyj journalctl, Krok 2b |
| Odmowa dostępu do pliku logu | auth.log jest dostępny tylko dla adm, secure jest tylko dla root | sudo, lub dodaj konto do adm |
| journalctl -u ssh zwraca nic nie, z sugestią 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 |
| Wylogowania są, ale brak linii Akceptowane | Filtracja według tagu (-t sshd) na OpenSSH 9.8+ | Filtruj według jednostki zamiast |
| Nic starszego niż ostatni restart | Dziennik ulotny; brak /var/log/journal | Stare dzienniki są zniknięte; sprawdź swój SIEM lub przesyłarkę logów |
| Plik obejmuje tylko kilka dni | Pliki obrotowe nie były włączone | Użyj komendy zgrep z auth.log* lub secure* |
| Stemple czasowe nie pasują do innych źródeł | Klasyczne stemple 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 czasem 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 dziennika, lub sudo zgrep -hE 'Failed|Invalid user’ /var/log/auth.log* gdy masz plik. Dla czegokolwiek więcej niż szybki przegląd, załaduj pełny log sshd zamiast. Niepowodzenia mają znaczenie tylko obok sukcesów.
A co z last i lastb?
Odczytują one binarne rejestry logowania w /var/log/wtmp i /var/log/btmp. Są przydatne do szybkiego przeglądu kto się zalogował, ale mają znacznie mniej szczegółów niż sam dziennik sshd i są równie łatwe do manipulacji przez intruza.
Jak mogę zbierać logi sshd z kilku serwerów jednocześnie?
Dla jednorazowego działania, pętla to robi: 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ło bez komunikatu o haśle po stronie zdalnej. W przeciwnym razie dodaj -t do ssh i wpisuj je za każdym razem. Jeśli robisz to częściej niż raz na kwartał, wyślij logi do SIEM zamiast.
Czy bezpiecznie jest przesyłać logi sshd do narzędzia online?
LogTotal anonimizuje przesłane pliki przed analizą i nie zachowuje plików; nasz [przewodnik dotyczący anonimizacji] pokazuje, co zostaje zamaskowane. Zasady dotyczące przetwarzania danych Twojej organizacji nadal mają pierwszeństwo.
Następny krok
Masz plik? Prześlij go do LogTotal i zobacz, co te 11 632 reguły sigma z niego wyciągną. Jeśli chcesz, aby ta sama logika detekcji działała na wszystkich twoich serwerach Linux, a nie jeden plik naraz.
Referencje
- Notatki dotyczące wydania Debian 12: zmiany w logowaniu systemowym
- Notatki wydania OpenSSH 9.8: rozdzielenie sshd / sshd-session i zmienione tagi logów
- journalctl(1): filtry jednostek, formaty wyjściowe, grupy dostępu do dzienników
- journald.conf(5): trwałe vs. ulotne przechowywanie
