☰

SSH schließt die Verbindung nach dem Login. Exit-Status 254

tag-icon • tag-icon linux ssh
SSH schließt die Verbindung nach dem Login. Exit-Status 254

Ich muss zunächst sagen, dass ich jedes einzelne Problem hier gelesen habe, das meins betrifft, aber alle scheinen irgendwie Zugriff auf die Dateien ihres Servers zu haben. Ich habe keinen, also hier meine Frage.

Ich verwende CentOS 6.5 und SSH schließt die Verbindung direkt nach einer erfolgreichen Anmeldung. Ich verwende Mac und Windows/Putty, um auf meinen Server zuzugreifen, mit den gleichen Ergebnissen. Gibt es jetzt eine Möglichkeit, auf meinen Server zuzugreifen, ohne Zugriff auf seine Dateien zu haben?

Unten sehen Sie die Ausgabe von ssh -vvv direkt nach einer erfolgreichen Anmeldung:

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

Antwort1

Zur Erinnerung: Dies war sicherlich ein Problem beim Forken der Benutzer-Shell. Diese können folgende Ursachen haben:

  1. ein Problem in Shell-Initialisierungsdateien
  2. ein Zustand, in dem nicht genügend Arbeitsspeicher vorhanden ist
  3. ein Zustand außerhalb der Prozesse

Dies ist eine sehr späte Antwort, aber in dieser Situation hätte ich beispielsweise versucht, einen Befehl direkt auszuführen: ssh server ls -ltraDadurch könnte die Shell-Initialisierung umgangen werden. Ich hätte mich als anderer Benutzer angemeldet, wodurch andere Shell-Initialisierungsdateien verwendet würden. Anschließend hätte ich einen Neustart durchgeführt, wodurch alle Probleme mit unzureichenden Ressourcen behoben werden sollten.

Antwort2

Ich habe die Konfiguration der geöffneten Dateien in der Kernel-Parameterdatei /etc/security/limits.conf auf unbegrenzt geändert und die Verbindung verloren.

Nachdem ich es wieder auf den Normalzustand für den Root-Benutzer zurückgesetzt hatte, konnte ich die Verbindung wiederherstellen.

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

verwandte Informationen