Como indica la pregunta anterior, tengo un servidor RHEL 6 que está diseñado para acceso SSH, y el root no puede iniciar sesión a través de SSH por diseño. Cuando estoy en el servidor localmente puedo iniciar sesión como root, pero sólo como root. Si intento iniciar sesión como usuario, en la pantalla aparece rápidamente un mensaje que dice:
Last Login: Mon Aug 24 08:24:52 on tty1
no directory: /home/user1!
logging in with home="/"
login: no shell: Permission denied
Recibo el mensaje sin shell porque no hay ningún shell en /.
Ahora bien, lo que es realmente confuso para mí es que el directorio de inicio realmente existe, contiene un shell válido y, por lo que puedo decir, tiene permisos ( 755). Esto es común para todos los usuarios que existieron y se crearon en esta instancia del servidor. Parece que no importa si defino una ruta al directorio de inicio cuando creo un usuario o dejo que el valor predeterminado se haga cargo y lo asigne automáticamente.
No encontré nada extraño en el registro seguro o en el registro de mensajes, solo que el usuario inició sesión exitosamente (lo cual es cierto, pero no puede hacer nada sin un shell)
Espero no necesitar reinstalar en este momento, pero casi no hay datos en el servidor que se perderían si esa fuera la única opción.
Cualquier ayuda sería muy apreciada ya que he buscado e intentado durante una semana sin suerte.
Editar:
Usé el useradd user1comando para agregar originalmente el usuario, cuando eso resultó en los problemas anteriores, usé
mkdir /home/user1 && useradd user1 -d /home/user1 && chown -R user:user1 /home/user
Cuando ejecuto el cat /etc/passwd | grep user1comando obtengo:
user1:x:513:517::/home/user1:bin/bash
y cuando ejecuto el ls -l /homecomando la entrada para ese usuario es:
drwxr-xr-x. 4 user1 user1 4096 Aug 19 17:03 user1
Respuesta1
Pude solucionar el problema ejecutando el comando.
for p in $(rpm -qa); do rpm --setperms $p; done
y reiniciando el servidor. Una vez que se reinició, no solo pude iniciar sesión como cualquier usuario que se hubiera creado, sino que también pude volver a usar la GUI. Esto apunta a permisos de archivos corruptos en alguna parte del sistema. No sé cómo se corrompieron, pero ahora todo funciona.
Respuesta2
El único problema que puedo ver con su configuración está en su archivo passwd. Intente cambiar
user1:x:513:517::/home/user1:bin/bash
a
user1:x:513:517::/home/user1:/bin/bash.
Respuesta3
Deben useraddcrear el directorio de inicio cuando se pasa la opción correcta y usted no tiene (o no debería) tener que crearlos manualmente. Le sugiero que ejecute lo siguiente (en el orden indicado) para eliminar y recrear su usuario correctamente.
userdel -f -r user1
useradd -m user1
NOTA: no es necesario que pase la -dopción ya que la opción predeterminada será /home/user1en este caso.
Respuesta4
Acabo de tener el mismo problema en una máquina CentOS 6. Este fue un problema con archivos en /home que tenían contextos de seguridad SELinux mal etiquetados. Uno de los comentaristas anteriores, Michael Hampton, quien dijo que verificar /var/log/audit/audit log fue acertado. Seguí su consejo y noté que había un problema con SELinux aquí. La solución que me solucionó fue:
sudo restorecon -Rv /home
Eso restaurará recursivamente las etiquetas de contexto de seguridad predeterminadas en todos los archivos en el directorio de inicio. Después de eso, se restableció el acceso ssh a través de clave pública.