¿Cómo verificar el registro de sshd?

126

Tengo Ubuntu 9.10 instalado sshdy puedo conectarme con éxito usando inicio de sesión y contraseña. He configurado un RSAinicio de sesión de clave y ahora tengo "El servidor rechazó nuestra clave" como se esperaba. Ok, ahora quiero verificar el sshdregistro para resolver un problema. He examinado /etc/ssh/sshd_configy tiene

SyslogFacility AUTH
LogLevel INFO

Okay. Estoy mirando /var/log/auth.logy ... está vacío O_O. Cambiar Loglevela VERBOSEnada ayuda, auth.logtodavía está vacío. ¿Alguna pista de cómo puedo verificar el sshdregistro?

ssh

— grigoryvp
fuente

77

¿Revisaste tu configuración de syslog? No ejecuto Ubuntu, pero puede redirigir la instalación de AUTH a un archivo de registro diferente. ¿Quizás / var / log / messages?

— Prof. Moriarty

¿Cómo verificar una configuración de syslog? Desafortunadamente, no soy muy bueno un linux :(. No cat /var/log/messages | grep sshmuestra nada :(.

— grigoryvp

Estás en lo correcto. /etc/syslog.confredirige AUTH a /var/logauth.log. Escribe tu respuesta para que pueda aceptarla :)

— grigoryvp

3

En mis servidores, sshd se registra en / var / log / secure. Esto se configura en /etc/rsyslog.conf, en la línea que comienza "authpriv. *"

— Isaac Betesh

1

authpriv ?? ¿Cómo diablos se suponía que supiéramos que tenía algo que ver con sshd? :-)

— Spencer Williams

7

Si nadie más está usando el sistema en este momento, podría hacer lo que hice en tales casos:

detener el servicio sshd (al menos he podido hacer esto mientras estaba conectado a través de ssh)
inicie sshd manualmente y agregue algunas opciones -d para obtener una salida de depuración más detallada. A menos que tenga algo funky, debe usar las mismas teclas y configurarlo cuando se inicia correctamente

— Peto
fuente

143

Detener SSHD en un servidor remoto es una muy mala idea. Esto puede resolver el problema para algunas (o la mayoría) de las configuraciones la mayor parte del tiempo, pero si CUALQUIER COSA sale mal (su conexión, alimentación en cualquier extremo, olvido, etc.) está fuera de la caja. Lo cual son malas noticias.

— Suprimido el

1

Bueno, debe tenerse en cuenta que la única forma en que podría iniciar el servicio después de detenerlo manualmente sería tener otro tipo de acceso a él, como otra conexión remota que no sea SSH, o estar sentado frente a él.

— Spencer Williams el

26

¿Cómo responde esto a la pregunta? Llegué aquí desde una búsqueda en la web esperando aprender cómo verificar los archivos de registro SSHD, no lo que funcionó para usted por algún problema ... Maldita sea, desearía que los lectores en la red de Stack Exchange realmente leyeran y respondieran la pregunta en cuestión, y no la pregunta que quieren que sea ....

44

Puede iniciar otro sshd en otro puerto. Conéctate a ese. Luego detenga el sshd principal e inicie uno nuevo en el puerto 22. Si algo falla, reinicie la caja utilizando su DRAC o la administración de la nube. Deberías haber comenzado sshd en el arranque, ¿verdad? Sin preocupaciones.

— Bruno Bronosky

1

@JoelESalas La comunidad no decide qué respuestas se aceptan.

— kasperd

155

Crear una respuesta basada en los comentarios anteriores, crédito a @Prof. Moriarty y @Eye of Hell

Las fallas de autenticación SSH se registran aquí /var/log/auth.log

Lo siguiente debería proporcionarle solo líneas de registro relacionadas con ssh

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

Para estar seguro, obtenga los últimos cientos de líneas y luego busque (porque si el archivo de registro es demasiado grande, grep en todo el archivo consumiría más recursos del sistema, sin mencionar que tardará más en ejecutarse)

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

— RAM
fuente

8

Esta respuesta Otra respuesta con flecha verde es falsa. Cambiar flecha.

— meshfields

55

¿Por qué no usar tail -f ...para monitorearlo en tiempo real? ¿Sería esto un problema con archivos de registro más grandes?

— ingh.am

66

less +F ...se 'colará' en tiempo real, y es mucho más poderoso que la cola

— northben

55

Y lnaves incluso mejor que menos / cola

— Wayne Werner

77

Ps: si su servidor es un Red Hat (como CentOS), la ruta del registro de registros sshd / login es / var / log / secure (verifique la carpeta / var / log para los archivos de registro de fechas específicas también). Vea esta respuesta: serverfault.com/questions/465833/…

— Brian Hellekin el

15

Si puede volver a intentar la conexión fallida fácilmente, una manera fácil es iniciar un servidor SSH en un puerto libre como 2222:

/usr/sbin/sshd -d -p 2222

y luego vuelva a intentar la conexión con:

ssh -p 2222 user@host

Al usar el puerto diferente -p 2222, no tenemos que detener el servidor SSH principal, lo que podría bloquearnos.

Ver también: https://unix.stackexchange.com/a/55481/32558

— Ciro Santilli 新疆改造中心法轮功六四事件
fuente

1

Una de las mejores opciones, especialmente si solo tiene acceso SSH a un servidor. La depuración de la conexión deteniendo el servidor ssh lo dejará fuera de sesión. Simplemente inicie un nuevo demonio ssh en un puerto diferente y pruebe el inicio de sesión con ese puerto.

— Atila Antal

1

Si desea ver todos los mensajes de registro sobre sshd, ejecute esto:

grep -rsh sshd /var/log |sort

— huésped
fuente

2

Los registros comenzarán con entradas como las Mar 14 19:52:04que excluyen el año y no se ordenan fácilmente (aunque puede tener la suerte de sort --month-sortsuponer que no supera un límite entre años). Los archivos de registro ya están ordenados, por lo que solo tiene que escanearlos en el orden correcto. Además, la grep -rllamada recursiva será realmente lenta en sistemas con registros grandes. No hay razón para escanear adicionalmente cosas como sus registros HTTPD.

— Adam Katz

1

Usted puede tail -f /var/log/auth.log

— Aditya Mittal
fuente

1

Bienvenido a ServerFault. ¿Leíste la pregunta? No está obteniendo datos en ese archivo. tailinútil si no tiene datos.

— pollitos

@chicks Eso es gracioso. La respuesta con la mayoría de los votos es casi la misma que esta ..

— Qback