/var/log/auth.log nie rejestruje nieudanych prób ssh

10

Próbuję przejść na moim serwerze (niepoprawna nazwa użytkownika, hasło lub jedno i drugie).

Zmieniłem / etc / ssh / sshd_config z

# Logging
SyslogFacility AUTH 
LogLevel INFO

do

# Logging
SyslogFacility AUTH 
LogLevel VERBOSE

i od tego czasu próbowałem wielu prób ssh zarówno z istniejącymi, jak i nieistniejącymi użytkownikami z losowymi hasłami, dlatego nie powiodło się. Podczas sprawdzania /var/log/auth.log nic się nie pojawia i jest całkowicie puste.

czego mi brakuje? Czy jakiś inny proces musi być zainstalowany i uruchomiony w moim systemie? Używam Ubuntu.

Wszelka pomoc lub wskazówki w tej sprawie są mile widziane.

Dzięki

ssh logging authentication

— edev.io
źródło

1

Czy zrestartowałeś sshd?

— bonsaiviking,

1

Jak wygląda twoja konfiguracja syslog? To będzie prawdopodobnie plik na /etc/syslog.conflub /etc/rsyslog.conflub/etc/rsyslog.d/*.conf

— Stefan Lasiewski

@StefanLasiewski pierwsze 2 są puste i /etc/rsyslog.d/*.confmówi „$ AddUnixListenSocket / var / spool / postfix / dev / log”

— edev.io

@Georgejnr: W takim przypadku wygląda na to, że konfiguracja syslog w twoim systemie jest zepsuta. Zwykle plik / syslog znajduje się w /etc/syslog.conf lub /etc/rsyslog.conf, i zwykle powinien znajdować się więcej niż jeden plik w /etc/rsyslog.d/*.conf. Czy ps auxpokazuje proces syslog?

— Stefan Lasiewski

@StefanLasiewski nie, nie ma go w ps aux. Poprzedni sysadmin był trochę nieuczciwy i celowo złamał kilka rzeczy, które wierzę. Myślisz, że to może być jego część? Jak mogę rozwiązać ten problem?

— edev.io,

6

LogLevel ogólnie (najwyraźniej zależny od aplikacji) odnosi się do jednego ze zdefiniowanych poziomów ważności obsługiwanych przez proces logowania do systemu (syslog). Więc zmień to z powrotem i zrestartuj serwer sshd.

Teraz, jeśli nie otrzymujesz danych wyjściowych, musisz spojrzeć na system /etc/syslog.conf i zobaczyć, co MINIMUM loglevel rejestruje żądania typu AUTH i do jakiego pliku. Błędy mogą dotyczyć innego pliku dziennika. LUB możesz nie rejestrować tych błędów z powodu konfiguracji syslog.conf dla usługi AUTH. Aby uzyskać więcej informacji, odwiedź strony podręcznika i syslog.conf.

— mdpc
źródło

From sshd_config (5) LogLevel: Podaje poziom szczegółowości używany podczas rejestrowania wiadomości z sshd (8). Możliwe wartości to: CICHY, FATAL, BŁĄD, INFORMACJE, VERBOSE , DEBUG, DEBUG1, DEBUG2 i DEBUG3.

— bonsaiviking,

1

mój /syslog.conf jest pusty. Muszę dodać, że przejmuję czyjś system i wygląda na to, że nie spisali się zbyt dobrze. Czy brak syslog.conf oznacza, że brakuje mi usługi? (dzięki za odpowiedź)

— edev.io

Plik znajduje się w /etc...... możliwe, że nic nie logujesz.

— mdpc,

O VERBOSE w sshd_config .... mój błąd, ale nie jest to poziom dziennika syslog, o który często pyta się w wielu programach, z którymi miałem do czynienia.

— mdpc,

pozostawiając VERBOSE nadal w moim sshd_config i uruchamiając sudo /etc/init.d/ssh restart, nadal nie loguje się. Czy jestem coś głupi?

— edev.io,

5

Kiedy miałem ten sam problem na Debianie, stwierdziłem, że muszę zrestartować rsyslogd:

/etc/init.d/rsyslog restart

(Twój program syslogd może się różnić.)

Zaczął pisać ponownie do /var/log/auth.log.

Być może przestało się rejestrować po zdarzeniu zapełnienia dysku, nie jestem pewien.

Zobacz także: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1059854/comments/9

— Sam Watkins
źródło

1

To działało dla mnie, ale zamiast tego użyłem systemctl do zrestartowania usługi syslog (Debian sid using inetutils-syslogd). systemctl restart inetutils-syslogd.service

— Brian Minton

3

W moim przypadku w głównym systemie plików nie było miejsca na dysku /, które można sprawdzić za pomocądf -h

— żółty
źródło

3

W moim przypadku problemem była własność /var/log/auth.logpliku. Był własnością, root:rootale musi być syslog:adm. Zamienić z

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

Wydaje się, że jest to powszechny problem w nowo tworzonych systemach - było więcej plików dziennika, które miały ten problem.