Conexión de cierre de Linux después de un inicio de sesión exitoso

Estoy trabajando en un servidor con Debian 5.2.2. Apenas teniendo algún conocimiento administrativo con Linux, creo que arruiné algo. Utilicé apt-get update y apt-get upgrade para actualizar todo y luego descargué e instalé Apache, PHP y MySQL. Esas herramientas parecen funcionar bien, pero ahora ni siquiera puedo iniciar sesión en el servidor EXCEPTO a través de la consola local. Si intento iniciar sesión a través de la GUI o si intento iniciar sesión de forma remota a través de ssh, scp o cualquier otra cosa, me desconecto INMEDIATAMENTE al iniciar sesión correctamente. En otras palabras, no tiene ningún problema con la conexión inicial, pero cuando pongo el nombre de usuario y la contraseña correctos (para root o cualquier usuario), me desconecto. Con la GUI, la pantalla se oscurece por un segundo y luego me devuelve a la solicitud de inicio de sesión. Con ssh, obtengo "conexión al [servidor] cerrada".

Se agradece cualquier ayuda, y si hay alguna forma en que pueda dar más información, hágamelo saber. Gracias por tu tiempo.

Ediciones:

- Cualquier usuario puede iniciar sesión en la consola local

- Por el momento no tengo acceso local a la máquina, así que todo lo que puedo hacer ahora es ssh. Aquí está la salida de ssh -vvv [servidor] después de ingresar mi contraseña:

Linux xxxxxxx.com 2.6.26.8+20091222+1056-debhawk-5.2.2-custom #1 SMP PREEMPT Tue Dec 22 10:58:57 EST 2009 i686

Last login: Mon Apr 30 14:48:07 2012 from xxxxxxx.com
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel 0: close_fds r -1 w -1 e 6
Connection to xxx.x.xx.xx closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3845.3
debug1: Exit status 254

Hay un par de publicaciones similares que sugieren que esto podría ser un problema para generar un shell debido a una configuración incorrecta de la ruta del shell en /etc/passwd

Para verificar esto, determine que su ruta de shell de usuario existe y es ejecutable;

# cat /etc/passwd | grep tomh
tomh:x:1000:1000:Tom H:/home/tomh:/bin/bash <-- check this exists

Comprobar shell existe:

# file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

También, comprobar que el depósito no está ajustado a /sbin/nologino /bin/false, lo que también bloquear el inicio de sesión, incluso con una autenticación exitosa.

http://www.linuxforums.org/forum/ubuntu-linux/173779-solved-ssh-issue.html
http://www.unix.com/hp-ux/169496-solved-ssh-debug1-exit-status -254-problem.html
http://www.mail-archive.com/seawolf-list@redhat.com/msg04460.html

Cuando me encontré con este problema, todavía tenía una conexión abierta / var / log / messages revelada:

pam_loginuid(sshd:session): Cannot open /proc/self/loginuid: Read-only file system

La edición de vi /etc/init.d/named permitió cambiar la forma en que se montó / proc, por lo que el error no se produjo después de un reinicio.

Básicamente las lineas

if [ ! -e "${CHROOT_PREFIX}/proc/meminfo" ]; then
mkdir -p “${CHROOT_PREFIX}/proc”
        mount -tproc -oro,nosuid,nodev,noexec proc ${CHROOT_PREFIX}/proc 2>/dev/null
fi;

Se cambiaron a

if [ ! -e "${CHROOT_PREFIX}/proc/meminfo" ]; then
mkdir -p “${CHROOT_PREFIX}/proc”
        mount –bind -o ro /proc “${CHROOT_PREFIX}/proc” 2>/dev/null
fi;

Un consejo que encontré en http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

Mi problema fue que el directorio de nombre de usuario de inicio de sesión no estaba disponible en el /homedirectorio. Entonces, si tiene un usuario llamado 'testuser', asegúrese de que el /home/testuserdirectorio esté disponible. Aprendí eso del /var/log/messagesarchivo.

debug3: channel 0: close_fds r -1 w -1 e 6
Connection to xxx.x.xx.xx closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3845.3
debug1: Exit status 254

En el sshd_configarchivo de su servidor SSH , agregue la siguiente línea:

UsePAM no

A continuación se muestra el sshd_configque uso en OS X. Lo publico (en lugar de uno en una máquina Debian) porque experimenté el mismo problema en OS X usando Macports (y no Debian).

AddressFamily any
ListenAddress 0.0.0.0
Port 1522

# The default requires explicit activation of protocol 1
Protocol 2

# HostKeys for protocol version 2
HostKey /opt/local/etc/ssh/ssh_host_ed25519_key
HostKey /opt/local/etc/ssh/ssh_host_ecdsa_key
HostKey /opt/local/etc/ssh/ssh_host_rsa_key
HostKey /opt/local/etc/ssh/ssh_host_dsa_key

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# User Authentication

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
UsePAM no

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

# Use sandbox on OS X
UsePrivilegeSeparation sandbox

# All user's environment
PermitUserEnvironment yes

# no default banner path
#Banner none

# override default of no subsystems
Subsystem   sftp    /opt/local/libexec/sftp-server

Si está utilizando LDAP, reemplace cada aparición de:

pam_unix_*.so

en todos los archivos en /etc/pam.d/ con:

pam_unix.so

Este es un error en el paquete libpam-ldap (archivos pam.d de ejemplo), consulte: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

Asegúrese de que el sistema pueda resolverse correctamente, ssh es un poco particular al respecto.

Verifique /etc/secuiry/limits.conf para ver si alguna cuenta tiene límites estrictos en la cantidad de inicios de sesión y aumente esos, es decir:

*       hard    maxlogins   0

Además de / var / log / messages como lo menciona Bram, también verifique /var/log/auth.log y pegue cualquier salida relevante. Demasiada información es mejor que muy poca.

De hecho, he encontrado exactamente estos síntomas de la manera sugerida por @ tom-h anteriormente ... y la resolución fue muy sencilla.

Para resolver, simplemente vipwy edite el archivo passwd, ajuste el shell de / bin / false a / bin / bash o la opción que prefiera.

# cat /etc/passwd | grep adamjohn
adamjohn:x:1000:1000:Adam John:/home/adamjohn:/bin/false <-- check this exists
# vi /etc/passwd
adamjohn:x:1000:1000:Adam John:/home/adamjohn:/bin/bash <-- change this item

Tenga en cuenta que, en algunos casos, esto podría hacerse para proteger una cuenta confidencial. Puede haber otras restricciones de acceso vigentes. Debe conocer la importancia de proteger el servidor y tener en cuenta las implicaciones de permitir este tipo de acceso.

Tuve problemas similares con Ubuntu 16.04 con LDAP. "ssh -vv ..." mostró que la autenticación de contraseña fue exitosa, pero luego apareció el mensaje: "Conexión a ... cerrada por host remoto".

Solucionado en /etc/ldap.conf en la configuración de "bind_policy".

/var/log/auth.log mostró:

sshd[19884]: Accepted password for xxxx from xx.xx.xx.xx port 48426 ssh2
sshd[19884]: pam_unix(sshd:session): session opened for user xxxx by (uid=0)
systemd-logind[577]: New session 22 of user xxxx.
systemd: pam_unix(systemd-user:session): session opened for user xxxx by (uid=0)
sshd[19884]: nss_ldap: could not search LDAP server - Server is unavailable
sshd[19884]: fatal: login_get_lastlog: Cannot find account for uid 1502 
sshd[19884]: pam_unix(sshd:session):   session closed for user xxxx

Encontró que el problema estaba en /etc/ldap.conf. Cambié bind_policy a "soft", por lo que nss_ldap regresa inmediatamente en caso de falla del servidor. El valor predeterminado es "hard_open", que se vuelve a conectar si falla la apertura de la conexión al servidor LDAP. Al comentar la línea "bind_policy soft", la cambió a la predeterminada y resolvió el problema. :-)

Después de mucha búsqueda, finalmente encontré una respuesta en el caso de CentOS 7 ejecutándose en un contenedor sin privilegios.

Comente la session required pam_loginuid.solínea en el archivo /etc/pam.d/sshd y luego reinicie el contenedor.

Encontré esta solución en https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119

Todas estas son excelentes sugerencias. En mi caso, fue una configuración PuTTY lo que causó mi dolor:

Había puesto un comando remoto para enviar al servidor en la configuración "SSH". Lo que funciona muy bien el 99% del tiempo, sin embargo, cuando el comando falla, simplemente cierra la sesión.

¿¿¿El comando??? pantalla -rd

Funciona muy bien cuando realmente hay una sesión para reanudar. Falla horriblemente después de un reinicio.

La solución:

mueve eso a bashrc / bash_profile.

En mi caso, fue causado por un usuario sin shell en un servidor SSH . Tiene una solución muy fácil, solo use el -Ninterruptor con su cliente (abierto) SSH.

Desde la página del manual :

-N No ejecute un comando remoto. Esto es útil solo para reenviar puertos.

Simplemente no puedo estar de acuerdo con algunas de las respuestas aquí. Un usuario con la cáscara /bin/false, /bin/nologines una configuración adecuada, se utiliza generalmente para los usuarios utilizan sólo para túneles SSH, sin la posibilidad de entrada y ejecutar los comandos en un servidor de SSH. Así que no intentes "arreglarlo" en el servidor, solo usa el -Ninterruptor con tu cliente SSH.

Asegúrese de que /etc/passwdtenga el shell correcto para el usuario.

Por ejemplo, el usuario ahmadno pudo iniciar sesión en el servidor debido a la falta de shell:

ahmad:x:10000:1003::/home/ahmad:/bin/false

Dado que el shell establecido en /bin/falseél significa que el usuario ahmadno tiene un shell, y para solucionar esto, debe cambiar /bin/falsea /bin/bashbash o cualquier otro shell.

Si está utilizando un panel de control de alojamiento web, por ejemplo, Plesk, asegúrese de que el usuario tenga la capacidad de acceder al servidor.

Puede ser un problema de LDAP. La configuración automática para configurar LDAP, Kerberos y SMB se ejecutó sin,

--enablemkhomedir