/var/log/auth.log non registra tentativi ssh non riusciti

10

Sto cercando di andare non riuscito (nome utente, password o entrambi errati) sul mio server.

Ho cambiato / etc / ssh / sshd_config da

# Logging
SyslogFacility AUTH 
LogLevel INFO

per

# Logging
SyslogFacility AUTH 
LogLevel VERBOSE

e da allora hanno tentato più tentativi di ssh con utenti sia esistenti che non esistenti con password casuali fallendo. Quando si controlla /var/log/auth.log non appare nulla ed è completamente vuoto.

Cosa mi sto perdendo? Alcuni altri processi devono essere installati e in esecuzione sul mio sistema? Sto eseguendo Ubuntu.

Qualsiasi aiuto o guida in merito è più che benvenuto.

Grazie

ssh logging authentication

— edev.io
fonte

1

Hai riavviato sshd?

— bonsaiviking,

1

Che aspetto ha la tua configurazione syslog? Questo sarebbe probabilmente un file a /etc/syslog.confo /etc/rsyslog.confo/etc/rsyslog.d/*.conf

— Stefan Lasiewski il

@StefanLasiewski i primi 2 sono vuoti e /etc/rsyslog.d/*.confdice "$ AddUnixListenSocket / var / spool / postfix / dev / log"

— edev.io

@Georgejnr: in tal caso, sembra che la configurazione di syslog sul tuo sistema sia interrotta. Di solito c'è un file syslog in /etc/syslog.conf o /etc/rsyslog.conf, e normalmente dovrebbe esserci più di un file in /etc/rsyslog.d/*.conf. Non ps auxmostrare un processo di syslog?

— Stefan Lasiewski il

@StefanLasiewski no non è elencato in ps aux. Il precedente amministratore di sistema è diventato un po 'malvagio e ha rotto alcune cose che credo apposta. Pensi che questo potrebbe farne parte? Come posso risolvere questo problema?

— edev.io,

6

LogLevel generalmente (apparentemente dipendente dall'applicazione) fa riferimento a uno dei livelli di gravità definiti supportati dal processo di registrazione del sistema (syslog). Quindi cambiarlo e riavviare il server sshd.

Ora, se non si ottiene l'output, è necessario esaminare il sistema /etc/syslog.conf e vedere quale MINIMO livello il tipo di richieste AUTH viene registrato e su quale file. Gli errori potrebbero essere indirizzati a un file di registro diverso. O potresti non registrare questi errori a causa della configurazione syslog.conf per il servizio AUTH. Per maggiori informazioni consultare le pagine man su e syslog.conf.

— MDPC
fonte

Da sshd_config (5) LogLevel: fornisce il livello di dettaglio usato durante la registrazione dei messaggi da sshd (8). I valori possibili sono: QUIET, FATAL, ERROR, INFO, VERBOSE , DEBUG, DEBUG1, DEBUG2 e DEBUG3.

— bonsaiviking,

1

il mio /syslog.conf è vuoto. Devo aggiungere che sto rilevando il sistema di qualcun altro e sembra che non abbiano fatto un ottimo lavoro nel configurarlo. La mancanza di syslog.conf significa che mi manca un servizio? (grazie per la risposta)

— edev.io

Il file è in /etc...... è possibile che tu non stia registrando nulla.

— mdpc,

Informazioni su VERBOSE in sshd_config .... errore mio, ma non è un livello di registro syslog che è comunemente richiesto in molti dei programmi che ho affrontato.

— mdpc,

lasciando VERBOSE ancora nel mio sshd_config ed eseguendo sudo /etc/init.d/ssh restart non si sta ancora registrando. Sono stupido per qualcosa?

— edev.io,

5

Quando ho avuto lo stesso problema su Debian, ho scoperto che dovevo riavviare rsyslogd:

/etc/init.d/rsyslog restart

(Il tuo programma syslogd può variare.)

Ha iniziato a scrivere di nuovo su /var/log/auth.log.

Forse ha smesso di registrare dopo un evento completo del disco, non ne sono sicuro.

Vedi anche: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1059854/comments/9

— Sam Watkins
fonte

1

Questo ha funzionato per me, ma usando systemctl invece per riavviare il servizio syslog (Debian sid usando inetutils-syslogd). systemctl restart inetutils-syslogd.service

— Brian Minton,

3

Nel mio caso non c'era spazio su disco a sinistra nel file system di root /, con il quale è possibile verificaredf -h

— yellowsir
fonte

3

Nel mio caso il problema riguardava la proprietà del /var/log/auth.logfile. Era di proprietà di root:rootma deve esserlo syslog:adm. Cambia con

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

Sembra essere un problema comune con i sistemi appena creati: c'erano più file di registro, che avevano questo problema.