Un mensaje de “fallo de autenticación PAM” no indica una solución universal. Primero, identifique qué servicio y usuarios presentan el problema y, a continuación, revise el registro en el momento correspondiente. En SUSE Linux Enterprise Server (SLES), repare un problema global de PAM confirmado mediante pam-configy modifique un archivo de servicio individual solo cuando su propia pila sea incorrecta. Mantenga una sesión de administrador o de root activa durante las pruebas; una pila PAM defectuosa puede bloquear nuevos inicios de sesión SSH y de consola.
La Guía de seguridad y protección de SLES 15 SP7 describe PAM como un conjunto de módulos de autenticación, cuenta, contraseña y sesión. Esta distinción es importante: una contraseña correcta puede superar esta authetapa y aun así ser rechazada posteriormente por una política de cuenta o una regla específica del servicio. Un mensaje de error genérico por sí solo no permite identificar qué etapa falló.
PAM actúa como intermediario entre una aplicación, como sshdel inicio de sesión en la consola, y los métodos de autenticación configurados. Cada servicio compatible con PAM tiene un archivo en /etc/pam.d/. El archivo de servicio puede incluir archivos comunes de SLES, como common-authy common-account, por lo que un fallo aislado en SSH puede tener una causa diferente a los fallos en todos los métodos de inicio de sesión.
Verificado: La pila SSH documentada de SUSE incluye pam_nologin.soarchivos PAM comunes. Si /etc/nologinexiste, el módulo documentado deniega el inicio de sesión a usuarios que no sean root. Depende del contexto: las reglas editadas localmente, los servicios de directorio y los módulos MFA de terceros pueden añadir comprobaciones adicionales. No se establece solo con el mensaje: que la contraseña sea incorrecta, que los archivos PAM estén dañados o que la cuenta esté bloqueada. Comience con el servicio afectado y su registro en lugar de reemplazar la pila.
Reproduzca el fallo una vez y anote la hora, el nombre de usuario y el método: SSH, consola de texto local, inicio de sesión gráfico, sudoo su. Si puede iniciar sesión como administrador, inspeccione los mensajes recientes del sistema:
sudo journalctl -eLa guía de solución de problemas de SLES de SUSE recomienda específicamente revisar el registro de errores de inicio de sesión y PAM. Busque el nombre del módulo o el motivo del intento en las proximidades de la hora exacta, como una cuenta denegada, un servicio de directorio no disponible, un módulo faltante o un error de archivo o permisos. No comparta los registros públicamente sin eliminar los nombres de usuario, los nombres de host, las direcciones y otros datos confidenciales.
Si solo falla SSH, inspeccione el registro del demonio SSH:
sudo journalctl -u sshd
Luego, compare las rutas de acceso. Si un usuario puede autenticarse en la consola local pero no mediante SSH, concéntrese en /etc/pam.d/sshdla política de acceso SSH o en un módulo específico de SSH. Si varios servicios rechazan a los mismos usuarios locales, inspeccione sus archivos compartidos common-*. Si solo un usuario falla, verifique el estado de la cuenta y la contraseña antes de cambiar la autenticación global del sistema.
Para un usuario local, compruebe primero el nombre de usuario, la distribución del teclado y la tecla Bloq Mayús. Si necesita restablecer las credenciales, utilice la herramienta de contraseñas aprobada por el administrador, como la de Gestión de Usuarios y Grupos de YaST, en lugar de editarlas /etc/shadowmanualmente. Si se deniega el acceso a todos los usuarios que no sean root mediante SSH, compruebe si existe un archivo de mantenimiento planificado /etc/nologinantes de modificar PAM; elimínelo solo si se confirma que el bloqueo de mantenimiento está obsoleto y usted está autorizado.
Para usuarios de LDAP, Active Directory u otros directorios, una contraseña válida en otro servidor no garantiza que este host SLES pueda acceder al proveedor de identidades. SUSE enumera entre las posibles causas problemas de red y DNS, desfase del reloj Kerberos, reglas PAM mal configuradas, política de acceso al host y directorios de inicio no disponibles. Compruebe si otro usuario del dominio puede iniciar sesión y si el usuario afectado puede iniciar sesión en un host diferente. A continuación, verifique la configuración del servicio de identidades y la conectividad del servidor.
Cuando el host utiliza SSSD, compruebe su servicio y si PAM está configurado para usarlo:
systemctl status sssd
sudo pam-config --query --sss
SSSD puede almacenar en caché la información del usuario y permitir la autenticación mientras el directorio no está disponible temporalmente, pero este comportamiento depende de su configuración y de las credenciales almacenadas en caché. Por lo tanto, una caché obsoleta o faltante es una posibilidad, no una conclusión. Verifique el DNS, la sincronización horaria para Kerberos, la accesibilidad del directorio y los registros de SSSD antes de borrar la caché o modificar los módulos. Si el proveedor de identidad informa "Cuenta bloqueada" o "Cuenta deshabilitada", pida al administrador del directorio que revise la política de esa cuenta; PAM informa la decisión, no necesariamente la crea.
Inspeccione el archivo específico del servicio y las reglas compartidas que incluye:
sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss
En SLES, pam-configse mantienen archivos globales en /etc/pam.d/common-*; los archivos de servicio individuales, como , /etc/pam.d/sshdse mantienen por separado. No edite manualmente los archivos comunes generados a menos que pam-configlos haya deshabilitado deliberadamente. Si confirma que este host debería usar SSSD y faltan sus reglas PAM de SSSD, consulte la documentación de SUSE sudo pam-config --add --ssspara agregarlas. Úselo solo después de confirmar que SSSD está configurado y en funcionamiento, y luego pruebe un nuevo inicio de sesión mientras la sesión administrativa activa permanece abierta.
Un error común, aunque peligroso, es creer que pam-config --createse trata de un comando de reparación inofensivo. SUSE indica que crea una configuración básica de autenticación Unix y sobrescribe los archivos preexistentes que no administra, conservando copias de seguridad. Esto puede eliminar la autenticación multifactor (MFA) personalizada o la autenticación de directorios. No lo ejecute como un paso de recuperación genérico. Para un error tipográfico en un archivo de servicio, restaure la configuración correcta y compatible con la versión de dicho servicio desde una copia de seguridad de confianza o modifique la línea defectuosa específica siguiendo el proceso de gestión de cambios de su organización.
Deje abierta la sesión original de administrador o de superusuario. Inicie una segunda sesión a través del mismo servicio que falló (por ejemplo, una nueva conexión SSH) y pruebe la cuenta afectada. Confirme que el registro ya no registra la misma denegación de PAM y que otro método de autenticación configurado sigue funcionando. Si el fallo persiste, capture la marca de tiempo exacta, el servicio, el nombre del módulo PAM y las líneas de registro relevantes (sin información confidencial); estos detalles son más útiles que el mensaje genérico de "fallo de autenticación".
pam-config.Instale las herramientas SLES 15 KVM y libvirt, habilite el servicio de host correcto y configure las máquinas virtuales seleccionadas para que se inicien después de un reinicio.
Utilice las tareas de systemd y el registro de arranque anterior para localizar un servicio lento, un punto de montaje o una dependencia de almacenamiento, y luego corríjalo sin enmascarar la causa.
Utilice firewall-cmd para inspeccionar la zona activa, permitir HTTP de forma segura, preservar el acceso SSH y verificar que la regla se mantenga tras una recarga en SLES 15.
Localice el fallo de PAM en su servicio, política de cuenta o proveedor de identidad, y luego repare la configuración SLES correcta manteniendo una sesión de administrador operativa.
Realice copias de seguridad de los archivos de Nextcloud y MariaDB conjuntamente, programe instantáneas Restic cifradas con cron y verifique la recuperación sin poner en riesgo el servidor en producción.
Permitir únicamente que las cuentas autorizadas inicien salas de Jitsi Meet mediante Keycloak y autenticación por token, manteniendo la opción de unirse como invitado cuando sea necesario.
Exporta un buzón individual de Zimbra Community Edition, valida su copia de seguridad TGZ y restaura los elementos que falten sin sobrescribir el correo existente.
Conecte ONLYOFFICE DocSpace a Active Directory u OpenLDAP, importe usuarios y grupos de forma segura, asigne campos de cuenta y programe una sincronización fiable.
Diagnosticar errores de memoria insuficiente (OOM kills) en MySQL en Debian 12, comprobar los límites de memoria del VPS, configurar el espacio de intercambio y ajustar la memoria y la concurrencia de la base de datos sin prometer una solución universal.
Instale fuentes personalizadas en ONLYOFFICE Document Server, compare los montajes persistentes de Docker con las copias directas, reconstruya la lista de fuentes y verifique el resultado.
