Comment vérifier le journal sshd?


126

J'ai installé Ubuntu 9.10 sshdet je peux y accéder avec succès en utilisant un identifiant et un mot de passe. J'ai configuré un RSAidentifiant de clé et j'ai maintenant "le serveur a refusé notre clé" comme prévu. Ok, maintenant je veux vérifier le sshdjournal afin de résoudre un problème. J'ai examiné /etc/ssh/sshd_configet il a

SyslogFacility AUTH
LogLevel INFO

D'accord. Je regarde /var/log/auth.loget ... c'est vide O_O. Changer Loglevelpour VERBOSEne auth.logsert à rien - est toujours vide. Des astuces pour vérifier mon sshdjournal?


7
Avez-vous vérifié votre configuration syslog? Je n'exécute pas Ubuntu, mais il se peut que le programme AUTH soit redirigé vers un autre fichier journal. Peut-être que / var / log / messages?
Prof. Moriarty

Comment vérifier une configuration syslog? Malheureusement, je ne suis pas très bon sous linux :(. cat /var/log/messages | grep ssh
Ne

Vous avez raison. /etc/syslog.confredirige AUTH vers /var/logauth.log. S'il vous plaît écrivez votre réponse afin que je puisse l'accepter :)
grigoryvp

3
Sur mes serveurs, sshd enregistre dans / var / log / secure. Ceci est configuré dans /etc/rsyslog.conf, sur la ligne commençant par "authpriv. *"
Isaac Betesh le

1
authpriv ?? Comment diable pouvions-nous savoir que cela avait un lien avec sshd? :-)
Spencer Williams

Réponses:


7

Si personne d'autre n'utilise le système pour le moment, vous pouvez faire ce que j'ai fait dans de tels cas:

  • arrêtez le service sshd (au moins, j'ai pu le faire en étant connecté via ssh)
  • démarrez sshd manuellement et ajoutez des options -d pour obtenir une sortie de débogage plus détaillée. À moins que quelque chose de funky ne se passe, il devrait utiliser les mêmes touches et le configurer quand il est démarré correctement

143
Arrêter SSHD sur un serveur distant est une très mauvaise idée. Cela peut résoudre le problème pour certaines (ou la plupart) des configurations la plupart du temps, mais en cas de problème, comme votre connexion, la mise sous tension, l’oubli, etc., vous êtes pris au dépourvu. Ce qui est une mauvaise nouvelle
Le

1
Il convient de noter que la seule façon de démarrer le service après l’arrêter manuellement serait d’y avoir un autre type d’accès, comme une autre connexion distante non-SSH, ou d’être assis devant.
Spencer Williams

26
Comment cela répond-il à la question? J'ai atterri ici à partir d'une recherche sur le Web espérant apprendre à vérifier les fichiers journaux SSHD, et non ce qui fonctionnait pour vous pour un problème donné… Bon sang, j'aimerais que les lecteurs du réseau Stack Exchange lisent et répondent à la question posée, et non la question, ils veulent que ce soit ....

4
Vous pouvez démarrer un autre sshd sur un autre port. Connectez-vous à celui-là. Arrêtez ensuite le fichier sshd principal et démarrez-en un nouveau sur le port 22. En cas de problème, redémarrez la boîte à l’aide de votre DRAC ou de la gestion en nuage. Vous devriez avoir sshd démarrant au démarrage non? Pas de soucis.
Bruno Bronosky

1
@JoelESalas La communauté ne décide pas quelles réponses sont acceptées.
Kasperd

155

En créant une réponse sur la base des commentaires ci-dessus, créditez @Prof. Moriarty et l'Eye of Hell

Les échecs d'authentification SSH sont consignés ici /var/log/auth.log

Ce qui suit ne devrait vous donner que les lignes de journal liées à ssh

grep 'sshd' /var/log/auth.log

Pour plus de sécurité, récupérez les quelques centaines de dernières lignes, puis effectuez une recherche (car si le fichier journal est trop volumineux, grep consomme plus de ressources système, sans compter que son exécution prendra plus de temps).

tail -500 /var/log/auth.log | grep 'sshd'


8
Cette réponse. Une autre réponse avec une flèche verte est fausse. Changer de flèche.
meshfields

5
Pourquoi ne pas utiliser tail -f ...pour le surveiller en temps réel? Serait-ce un problème avec des fichiers journaux plus volumineux?
ingh.am

6
less +F ...'queue' en temps réel, et c'est beaucoup plus puissant que la queue
northben

5
Et lnavc'est encore mieux que moins / queue
Wayne Werner

7
Ps: si votre serveur est un serveur Red Hat (comme CentOS), le chemin du journal des enregistrements sshd / login est / var / log / secure (recherchez également dans le dossier / var / log les fichiers journaux de dates spécifiques). Voir cette réponse: serverfault.com/questions/465833/…
Brian Hellekin

15

Si vous pouvez essayer à nouveau facilement la connexion défaillante, un moyen simple consiste à démarrer un serveur SSH sur un port libre tel que 2222:

/usr/sbin/sshd -d -p 2222

puis réessayez la connexion avec:

ssh -p 2222 user@host

En utilisant le port différent -p 2222, nous n’avons pas à arrêter le serveur SSH principal, ce qui pourrait nous bloquer.

Voir aussi: https://unix.stackexchange.com/a/55481/32558


1
Une des meilleures options, spécialement si vous n’avez qu’un accès SSH à un serveur. Le débogage de la connexion en arrêtant le serveur ssh vous fera quitter la session. Il suffit de démarrer un nouveau démon ssh sur un autre port et de tester la connexion à l'aide de ce port.
Attila Antal

1

Si vous voulez voir tous les messages du journal concernant sshd, lancez ceci:

grep -rsh sshd /var/log |sort

2
Les journaux commenceront par des entrées telles Mar 14 19:52:04que celles- ci excluent l’année et ne sont pas faciles à trier (même si vous pouvez avoir de la chance de sort --month-sortsupposer que vous ne dépassez pas une limite entre les années). Les fichiers journaux eux-mêmes sont déjà triés, il vous suffit donc de les analyser dans le bon ordre. En outre, l' grep -rappel récursif sera très lent sur les systèmes avec des journaux volumineux. Il n'y a aucune raison d'analyser en outre des éléments tels que vos journaux HTTPD.
Adam Katz

1

Vous pouvez tail -f /var/log/auth.log


1
Bienvenue sur ServerFault. Avez-vous lu la question? Il ne reçoit pas de données dans ce fichier. tailinutile si elle ne contient aucune donnée.
poussins

@chicks C'est drôle. La réponse avec le plus de votes est presque la même chose comme ça ..
Qback
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.