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.Configure Nextcloud para que elimine los archivos borrados después de un período de retención definido, programe tareas en segundo plano de forma fiable y evite comandos que vacíen la papelera de todos los usuarios.
Ejecuta la reparación de OCC de Nextcloud de forma segura, previsualiza los cambios en la base de datos y comprueba por qué persiste la advertencia.
Permita la carga de archivos más grandes en el navegador Nextcloud alineando la configuración de PHP, Nginx o Apache, el almacenamiento temporal y el tiempo de espera, y verifique qué límite está bloqueando el archivo.
Establezca el límite de memoria PHP que Nextcloud utiliza realmente, reinicie el servicio correcto y confirme la configuración de 512 MB en la Vista general de administración.
Monta un bucket de almacenamiento de objetos compatible en Nextcloud utilizando su backend S3, con el punto final, las credenciales, el ámbito de acceso y los pasos de verificación correctos.
Traslada de forma segura un directorio de datos de Linux Nextcloud a una unidad externa utilizando un montaje UUID persistente, el modo de mantenimiento, una copia verificada y el enlace simbólico de la ruta original.
Restaure el acceso a Nextcloud después de una actualización diagnosticando errores SQL, comprobando la conectividad de la base de datos y completando de forma segura las migraciones interrumpidas.
Utilice el comando OCC de Nextcloud para restablecer la contraseña de administrador desde la consola del servidor, con instrucciones sobre nombres de usuario, permisos y proveedores de inicio de sesión externos.
Elimine la advertencia HSTS de Nextcloud configurando el encabezado en Apache, NGINX o su proxy TLS, y luego verifique la respuesta HTTPS pública de forma segura.
Identificar los fallos de instalación de la App Store y determinar si se deben a problemas de DNS, HTTPS, proxy, TLS o configuración del propio servidor Nextcloud.
