/var/log/auth.log ne consigne pas les tentatives ssh échouées

10

J'essaie de faire échouer (nom d'utilisateur, mot de passe ou les deux) sur mon serveur.

J'ai changé / etc / ssh / sshd_config de

# Logging
SyslogFacility AUTH 
LogLevel INFO

à

# Logging
SyslogFacility AUTH 
LogLevel VERBOSE

et ont depuis tenté plusieurs tentatives ssh avec des utilisateurs existants et non existants avec des mots de passe aléatoires, échouant ainsi. Lors de la vérification de /var/log/auth.log, rien n'apparaît et il est entièrement vide.

Qu'est-ce que je rate? Un autre processus doit-il également être installé et exécuté sur mon système? J'utilise Ubuntu.

Toute aide ou orientation à ce sujet est plus que bienvenue.

Merci

ssh logging authentication edev.io
la source
1
Avez-vous redémarré sshd?
bonsaiviking
1
À quoi ressemble votre configuration syslog? Ce serait probablement un fichier à /etc/syslog.confou /etc/rsyslog.confou/etc/rsyslog.d/*.conf
Stefan Lasiewski
@StefanLasiewski les 2 premiers sont vides et /etc/rsyslog.d/*.confdisent "$ AddUnixListenSocket / var / spool / postfix / dev / log"
edev.io
@Georgejnr: Si tel est le cas, il semble que la configuration syslog de votre système soit rompue. Il y a normalement un fichier syslog sous /etc/syslog.conf ou /etc/rsyslog.conf, et normalement il devrait y avoir plus d'un fichier sous /etc/rsyslog.d/*.conf. Affiche ps auxun processus syslog?
Stefan Lasiewski
@StefanLasiewski non, il n'est pas répertorié dans ps aux. L'administrateur système précédent est devenu un peu voyou et a cassé exprès certaines choses que je crois. Vous pensez que cela pourrait en faire partie? Comment résoudre ce problème?
edev.io

Réponses:

6

LogLevel fait généralement référence à l'un des niveaux de gravité définis pris en charge par le processus de journalisation système (syslog) (apparemment dépendant de l'application). Alors changez-le et redémarrez le serveur sshd.

Maintenant, si vous n'obtenez pas la sortie, vous devez regarder le système /etc/syslog.conf et voir quel niveau de journalisation MINIMUM le type de demandes AUTH est enregistré et dans quel fichier. Les erreurs peuvent aller dans un autre fichier journal. OU vous ne consignerez peut-être pas ces erreurs en raison de la configuration syslog.conf pour le service AUTH. Pour plus d'informations, consultez les pages de manuel sur et syslog.conf.

mdpc
la source
From sshd_config (5) LogLevel: Donne le niveau de verbosité utilisé lors de la journalisation des messages de sshd (8). Les valeurs possibles sont: SILENCIEUX, FATAL, ERREUR, INFO, VERBOSE , DEBUG, DEBUG1, DEBUG2 et DEBUG3.
bonsaiviking
1
mon /syslog.conf est vide. Je dois ajouter que je reprends le système de quelqu'un d'autre et il semble qu'ils n'ont pas très bien réussi à le mettre en place. Le manque de syslog.conf signifie-t-il que je manque un service? (merci pour votre réponse)
edev.io
Le fichier est dans /etc...... il est possible que vous ne consigniez rien.
mdpc
À propos de VERBOSE dans sshd_config .... mon erreur, mais ce n'est pas un niveau de journal syslog qui est couramment demandé dans de nombreux programmes que j'ai traités.
mdpc
en laissant VERBOSE toujours dans mon sshd_config et en exécutant sudo /etc/init.d/ssh redémarrer, il ne se connecte toujours pas. Suis-je stupide à propos de quelque chose?
edev.io
5

Quand j'ai eu le même problème sur Debian, j'ai trouvé que je devais redémarrer rsyslogd:

/etc/init.d/rsyslog restart

(Votre programme syslogd peut varier.)

Il a recommencé à écrire dans /var/log/auth.log.

Peut-être qu'il avait cessé de se connecter après un événement de disque plein, je ne suis pas sûr.

Voir également: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1059854/comments/9

Sam Watkins
la source
1
Cela a fonctionné pour moi, mais en utilisant systemctl à la place pour redémarrer le service syslog (Debian sid en utilisant inetutils-syslogd). systemctl restart inetutils-syslogd.service
Brian Minton
3

Dans mon cas, il n'y avait pas d'espace disque à gauche sur le système de fichiers racine /, que vous pouvez vérifier avecdf -h

yellowsir
la source
3

Dans mon cas, le problème était lié à la propriété du /var/log/auth.logfichier. Il appartenait à root:rootmais doit l'être syslog:adm. Echanger avec

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

Cela semble être un problème commun avec les systèmes nouvellement créés - il y avait plus de fichiers journaux, qui avaient ce problème.


la source