Frage Linux schließende Verbindung nach erfolgreicher Anmeldung


Ich arbeite an einem Server mit Debian 5.2.2. Ich habe kaum administrative Kenntnisse mit Linux, glaube ich, dass ich etwas vermasselt habe. Ich habe apt-get update und apt-get upgrade verwendet, um alles auf den neuesten Stand zu bringen, und dann habe ich Apache, PHP und MySQL heruntergeladen und installiert. Diese Tools scheinen gut zu funktionieren, aber jetzt kann ich mich nicht mehr über die lokale Konsole am Server anmelden. Wenn ich versuche, mich über die GUI anzumelden oder wenn ich versuche, mich per ssh, scp oder irgendetwas anderem anzumelden, werde ich bei erfolgreicher Anmeldung sofort getrennt. Mit anderen Worten, es hat kein Problem mit der ersten Verbindung, aber wenn ich den richtigen Benutzernamen und das richtige Passwort (für root oder einen anderen Benutzer) eingegeben habe, werde ich getrennt. Mit der GUI wird der Bildschirm für eine Sekunde schwarz und bringt mich dann direkt zurück zur Login-Eingabeaufforderung. Mit ssh bekomme ich "Verbindung zu [Server] geschlossen." Ich habe versucht WinSCP und ich bekomme "Verbindung wurde unerwartet geschlossen. Server gesendet Befehl beenden Status 254."

Jede Hilfe wird geschätzt, und wenn es irgendeinen Weg gibt, um mehr Informationen zu geben, lass es mich wissen. Vielen Dank für Ihre Zeit.

Bearbeitungen:

- Jeder Benutzer kann sich an der lokalen Konsole anmelden

- Im Moment habe ich keinen lokalen Zugriff auf die Maschine, also kann ich jetzt nur noch ssh. Hier ist die Ausgabe von ssh -vvv [Server] nachdem ich mein Passwort eingegeben habe:

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

21
2018-04-30 18:53


Ursprung


Linux ist ein Kernel, kein Betriebssystem. Es gibt keine Kernel-Version 5.2.2, na und? Verteilung benutzt du? - Sven♦
Melden Sie sich über die Konsole an und überprüfen Sie die /var/log/messages und /car/log/secure protokolliert, wenn Sie versuchen, sich remote anzumelden. Versuchen Sie, sich mit einzuloggen ssh -vvv <servername> damit Sie sehen können, was schief läuft. dmesg Ausgabe könnte auch nützlich sein, aber Sie müssen nur relevante Teile trimmen und veröffentlichen. Können Sie sich mit einem Benutzerkonto auf der lokalen Konsole oder nur mit root anmelden? Wird der SSH-Daemon ausgeführt (ps auxwww|grep ssh) - Bram


Antworten:


Es gibt ein paar ähnliche Beiträge, die darauf hindeuten, dass dies ein Problem beim Erstellen einer Shell sein könnte, da der Shell-Pfad in den Einstellungen falsch ist /etc/passwd

Um dies zu überprüfen, stellen Sie fest, dass Ihr Benutzer-Shell-Pfad existiert und ausführbar ist;

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

Prüfe, ob die Shell existiert:

# 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

Stellen Sie außerdem sicher, dass die Shell nicht auf beides eingestellt ist /sbin/nologin oder /bin/false, die auch bei einer erfolgreichen Authentifizierung die Anmeldung blockieren würde.

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 


22
2018-05-01 04:07



Das war in der Tat mein Problem, bei einer frischen Cygwin-Installation hatte der von der Installation erstellte Benutzer einen Benutzerpfad von / bin / false. Durch das Ändern dieser Einstellung in / bin / bash wurde das Problem behoben. Vielen Dank! - Mitch Kent
Nach meiner Erfahrung ist es ratsam, die Shell beim Erstellen des Benutzers anzugeben. Die Standardeinstellung variiert von dist bis dist. - MetalGodwin


Mein Problem war Login Benutzername Verzeichnis war nicht verfügbar in der /home Verzeichnis. Also, wenn Sie einen Benutzer namens 'testuser' haben, stellen Sie sicher, dass /home/testuser Verzeichnis ist verfügbar. Gelernt, dass von der /var/log/messages Datei.


3
2017-07-12 11:02



Überprüfen Sie auf jeden Fall die /var/log/messages/auth.log für Zeiger. Hatte auch ein Dateiproblem - Nick


Als ich auf ein solches Problem stieß, hatte ich immer noch eine Verbindung geöffnet / var / log / messages aufgedeckt:

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

Bearbeiten von vi /etc/init.d/named erlaubt den Pfad zu ändern / proc wurde gemountet, so dass der Fehler nach einem Neustart nicht aufgetreten ist.

Grundsätzlich die Linien

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;

Wurden zu geändert

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

Ein Tipp, den ich gefunden habe http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905


2
2018-03-07 17:08



Willkommen bei SF. Sie können den Stil Ihrer Antwort verbessern, indem Sie den Code mit 4 Leerzeichen einrücken (oder Backticks um ihn herum verwenden). - ℝaphink


Wenn Sie LDAP verwenden, ersetzen Sie jedes Vorkommen von:

pam_unix_*.so

in allen Dateien in /etc/pam.d/ mit:

pam_unix.so

Dies ist ein Fehler im libpam-ldap-Paket (Beispiel pam.d-Dateien), siehe: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

Stellen Sie sicher, dass das System ordnungsgemäß aufgelöst werden kann, ssh ist ein bisschen speziell.

Überprüfen Sie /etc/secuiry/limits.conf, ob bei Konten die Anzahl der Anmeldungen stark begrenzt ist und erhöhen Sie diese, z.

*       hard    maxlogins   0

Zusätzlich zu / var / log / messages wie von Bram erwähnt, überprüfe auch /var/log/auth.log und füge bitte alle relevanten Ausgaben ein. Zu viel Information ist besser als zu wenig.


1
2018-04-30 23:07





Ich habe tatsächlich genau diese Symptome in der von @ tom-h früher vorgeschlagenen Weise angetroffen ... und die Auflösung war sehr einfach.

Einfach zu lösen vipw Bearbeiten Sie die passwd-Datei und passen Sie die Shell von / bin / false an / bin / bash oder die Option Ihrer Präferenz an.

# 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

Bitte haben Sie Verständnis dafür, dass dies in einigen Fällen geschehen könnte, um ein sensibles Konto zu schützen. Möglicherweise bestehen weitere Zugriffsbeschränkungen. Sie sollten wissen, wie wichtig es ist, den Server zu schützen, und sich der Auswirkungen bewusst sein, die diese Art des Zugriffs auf diesen Server haben.


1
2017-11-22 17:01





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

In Ihrem SSH-Server sshd_config Datei, füge die folgende Zeile hinzu:

UsePAM no

Unten ist das sshd_config Ich benutze es unter OS X. Ich poste es (anstatt eines auf einer Debian-Maschine), weil ich das gleiche Problem unter OS X mit Macports (und nicht Debian) hatte.

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

1
2017-12-27 20:02





All das sind großartige Vorschläge. In meinem Fall war es ein PuTTY-Setting, das meinen Schmerz verursachte:

Ich hatte einen Remote-Befehl zum Senden an den Server unter "SSH" Konfiguration. Das funktioniert zu 99%, wenn der Befehl fehlschlägt, wird die Sitzung jedoch geschlossen.

Der Befehl??? Bildschirm -rd

Funktioniert hervorragend, wenn eine Sitzung neu gestartet werden soll. Scheitert nach einem Neustart schrecklich.

Die Lösung:

verschiebe das nach bashrc / bash_profile.


0
2018-03-09 20:15





In meinem Fall war es das verursacht durch einen Benutzer ohne eine Shell auf einem SSH-Server. Es hat eine sehr einfache Lösung, benutzen Sie einfach die -N wechseln Sie mit Ihrem (offenen) SSH-Client.

Von dem Man Seite:

-N     Führen Sie keinen Remote-Befehl aus. Dies ist nützlich für das Weiterleiten von Ports.

Ich kann einigen Antworten hier nicht zustimmen. Ein Benutzer mit der Shell /bin/false, /bin/nologin ist eine ordnungsgemäße Konfiguration, wird normalerweise für Benutzer verwendet, die nur für SSH-Tunnel verwendet werden, ohne die Möglichkeit, sich an einem SSH-Server anzumelden und Befehle auszuführen. Versuchen Sie also nicht, es auf dem Server zu "reparieren", benutzen Sie einfach die -N Wechseln Sie mit Ihrem SSH-Client.


0
2018-01-04 18:37





Stelle sicher das /etc/passwd hat die richtige Shell für den Benutzer.

Zum Beispiel der Benutzer ahmad konnte sich aufgrund fehlender Shell nicht am Server anmelden:

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

Seit der Shell auf eingestellt /bin/false es bedeutet der Benutzer ahmad hat keine Shell, und um das zu beheben, musst du dich ändern /bin/false zu /bin/bash für Bash oder was auch immer andere Muscheln.

Wenn Sie ein Webhosting-Kontrollfeld verwenden, z. Stellen Sie sicher, dass der Benutzer auf den Server zugreifen kann.


0
2018-04-25 19:22





Ich hatte ähnliche Probleme mit Ubuntu 16.04 mit LDAP. "ssh -vv ..." zeigte, dass die Passwortauthentifizierung erfolgreich war, aber dann kam die msg: "Verbindung zu ... geschlossen vom Remote-Host".

In /etc/ldap.conf in der Konfiguration von "bind_policy" behoben.

/var/log/auth.log zeigte:

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

Das Problem wurde in /etc/ldap.conf gefunden. Ich habe die bind_policy auf "soft" geändert, so dass nss_ldap sofort beim Serverausfall zurückkehrt. Der Standardwert ist "hard_open". Er wird wiederhergestellt, wenn die Verbindung zum LDAP-Server fehlgeschlagen ist. Durch das Auskommentieren der Zeile "bind_policy soft" wurde der Standard zurückgesetzt und das Problem gelöst. :-)


0
2017-09-18 17:19