SSH cierra la conexión después de iniciar sesión Estado de salida 254

SSH cierra la conexión después de iniciar sesión Estado de salida 254

Necesito comenzar diciendo que he leído todos los problemas aquí relacionados con el mío, pero todos parecen tener acceso de alguna manera a los archivos de su servidor. No lo hago, así que aquí está mi pregunta.

Estoy en centOS 6.5 y ssh cierra la conexión inmediatamente después de iniciar sesión correctamente. Estoy usando mac y windows/putty para acceder a mi servidor con los mismos resultados. ¿Existe alguna forma de poder acceder a mi servidor ahora sin tener acceso a sus archivos?

A continuación se muestra la lectura de ssh -vvv justo después de iniciar sesión correctamente:

debug1: Authentication succeeded (password).
Authenticated to 4X.5X.XX.2 ([4X.5X.XX.2]:82).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Oct  7 06:23:21 2015 from 1XX.XXX.X1.185
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
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
debug2: channel 0: rcvd close
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 cc -1)

Connection to 4X.5X.XX.2 closed.
Transferred: sent 3176, received 2640 bytes, in 0.3 seconds
Bytes per second: sent 10370.6, received 8620.4
debug1: Exit status 254

Respuesta1

Para que conste, esto fue ciertamente un problema al bifurcar el shell del usuario. Estos pueden ser causados ​​por:

  1. un problema en los archivos de inicialización del shell
  2. una condición de falta de memoria
  3. una condición fuera de proceso

Esta es una respuesta muy tardía, pero en esta situación habría intentado ejecutar un comando directamente, por ejemplo: ssh server ls -ltraque podría omitir alguna inicialización del shell, iniciar sesión como otro usuario que usaría algunos archivos de inicialización del shell diferentes y luego reiniciar, lo cual debería solucionar cualquier condición de falta de recursos.

Respuesta2

Cambié la configuración de archivos abiertos en el archivo de parámetros del kernel /etc/security/limits.conf a ilimitada y perdí la conectividad.

Después de revertirlo a la normalidad para el usuario root, recuperé la conectividad.

Wrong Example:
## Example hard limit for max opened files
*        hard   nofile unlimited
root     hard   nofile  unlimited
## Example soft limit for max opened files
*        soft   nofile unlimited
root     soft   nofile unlimited

Correct Ex:
## Example hard limit for max opened files
*        hard   nofile 16000
root     hard   nofile 16000
## Example soft limit for max opened files
*        soft   nofile 16000
root     soft   nofile 16000

información relacionada