Lo más reciente que recuerdo es cambiar el ulimit suave y duro de memlock a ilimitado. Ahora no puedo meterme en la máquina.
Este es el registro ssh.
Authenticated to IP ([IP]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LC_CTYPE =
debug2: channel 0: request env confirm 0
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 Aug 6 07:18:07 2014 from IP-SOURCE
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
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd 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
Connection to IP closed.
Transferred: sent 4256, received 2504 bytes, in 0.4 seconds
Bytes per second: sent 9616.9, received 5658.0
debug1: Exit status 254
He intentado lo siguiente sin éxito hasta ahora, antes de publicar aquí:
Intentando un inicio de sesión de perfil normal por
ssh user@host 'bash --noprofile'
Forzando un tty por
ssh -t user@host
Movido el bash_profile. Traté de pasar por alto
ssh user@host
.Cambiar el nombre del
limits.conf
archivo con la esperanza de que no se lea.Se reinició el servidor ssh.
Ejecute un comando a través de
knife
comoknife ssh "name:server" "come_command"
ssh user@host 'ulimit -l 64'
,ssh user@host 'ulimit -S -l 64'
,ssh user@host 'ulimit -H -l 64'
,ssh user@host 'exec ulimit -H -l 64'
No estoy seguro de si esta forma de ejecutar comandos en línea: ssh user@host "some_command"
funciona, porque no puedo obtener una simple lista de directorios. También intenté reiniciar ssh user@host 'reboot'
pero no creo que se haya ejecutado el comando. Reinicié la máquina desde AWS también, pero no tuve éxito.
¿Es una causa perdida tratando de ssh? ¿Hay alguna manera de que pueda ingresar al servidor?
SSH_FXP_INIT
código de error.-v
opción, o para más, la-vv
opción de incluso más, luego la-vvv
opción. Por ejssh -vvv user@host
. Eso puede darle una mejor idea de dónde van las cosas mal.Respuestas:
Trata de cambiar
en
en
/etc/ssh/sshd_config
(para CentOS)fuente
/etc/security/limits.conf
manguera y pam no puede usarlo más.systemd
esta es una mala solución en mi humilde opinión. Esto evitarálogind
que se abra una sesión y cuando / si el usuario reinicia la máquina, algunos procesos se iniciaron ya que el usuario no se detendrá como se esperaba.nr_open
. (nr_open
Se restablece al reiniciar la máquina): se puede comprobar elnr_open
porcat /proc/sys/fs/nr_open
y abrir archivos de disco duroulimit -Hn
. Si aún desea que el usuario de inicio de sesión ssh use la configuración de archivo de apertura dura, debe aumentarnr_open
:sudo sysctl -w fs.nr_open=NUM_BIGGER_THAN_HARD
Tuve un problema similar, parecía que solo veía el siguiente mensaje extraño:
El usuario con el que intentaba ingresar no tenía un shell predeterminado .
Ejecuté lo siguiente:
Y luego pude
ssh
.Nota: La
ejecución
su username
estaba devolviendo el código de salida1
(estaba fallando) y ahora simplemente funciona.fuente
Encontré esto en Mac OS X, donde la configuración
~/.bashrc
tuvo un problema que hizossh
que funcionara, perosftp
que no funcionara. @ stéphane-chazelas parece tener la idea correcta en los comentarios anteriores.En el sistema remoto a través de SSH, cambie el nombre y vuelva
~/.bashrc
a~/.bashrc-MOVED
intentarlo para ver si funciona; luego restaure~/.bashrc
y determine el problema.En mi sistema
~/.bashrc
contenía esto:Cuál era el probable culpable.
fuente
Tuve el mismo problema hoy. Lo primero que noté fue que / var / log estaba al 100%. Lo arreglé y no resolvió el problema. No pude ingresar ni pude iniciar sesión a través de la GUI, pero pude CNTRL + ALT + F2 para llegar a CLI e iniciar sesión de esa manera. Escribí startx y recibí un error de que /tmp/.X0-lock existía.
Eliminé ese archivo (técnicamente eliminé todo de / tmp) y pude iniciar sesión a través de GUI y también a través de ssh.
fuente
/home
llenó hasta el 100%, lo que he detectado usandodf -h
CentOS 7.Cambié la configuración de Abrir archivos en el archivo de parámetros del núcleo /etc/security/limits.conf a ilimitado y perdí la conectividad.
Después de volver a la normalidad para el usuario root, recuperé la conectividad.
fuente