Linux-Verbindung wird nach erfolgreicher Anmeldung geschlossen

Ich arbeite auf einem Server mit Debian 5.2.2. Ich habe kaum administrative Kenntnisse über Linux und denke, ich habe etwas vermasselt. Ich habe apt-get update und apt-get upgrade verwendet, um alles auf den neuesten Stand zu bringen, und dann Apache, PHP und MySQL heruntergeladen und installiert. Diese Tools scheinen gut zu funktionieren, aber jetzt kann ich mich nicht einmal über die lokale Konsole auf dem Server anmelden, AUSSER. Wenn ich versuche, mich über die GUI anzumelden, oder wenn ich versuche, mich remote über ssh, scp oder irgendetwas anderes anzumelden, werde ich SOFORT nach erfolgreicher Anmeldung von der Verbindung getrennt. Mit anderen Worten, es gibt kein Problem mit der anfänglichen Verbindung, aber wenn ich den richtigen Benutzernamen und das richtige Passwort (für root oder einen beliebigen Benutzer) eingebe, wird die Verbindung getrennt. Mit der GUI wird der Bildschirm für eine Sekunde schwarz und ich kehre direkt zur Anmeldeaufforderung zurück. Mit ssh bekomme ich "Verbindung zu [Server] geschlossen".

Jede Hilfe wird gebeten, und wenn ich weitere Informationen geben könnte, lassen Sie es mich bitte 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. Alles, was ich jetzt tun kann, ist 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

Es gibt einige ähnliche Posts, die darauf hindeuten, dass dies ein Problem beim Laichen einer Shell sein könnte, da die Einstellungen für den Shell-Pfad in falsch sind /etc/passwd

Um dies zu überprüfen, stellen Sie sicher, dass Ihr Benutzer-Shell-Pfad vorhanden und ausführbar ist.

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

Überprüfen Sie, ob die Shell vorhanden ist:

# 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 entweder /sbin/nologinoder eingestellt ist /bin/false, was auch bei erfolgreicher 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

Als ich auf ein solches Problem stieß, war immer noch eine Verbindung offen / var / log / messages:

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

Das Bearbeiten von vi /etc/init.d/named ermöglichte es, die Art und Weise zu ändern, in der / proc gemountet wurde, sodass der Fehler nach einem Neustart nicht auftrat.

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 geändert zu

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

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

Mein Problem war Login Benutzername Verzeichnis war nicht im /homeVerzeichnis verfügbar . Wenn Sie also einen Benutzer mit dem Namen "Testbenutzer" haben, stellen Sie sicher, dass das /home/testuserVerzeichnis verfügbar ist. Das habe ich aus der /var/log/messagesAkte gelernt .

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

Fügen Sie in der sshd_configDatei Ihres SSH-Servers die folgende Zeile hinzu:

UsePAM no

Unten ist das, was sshd_configich unter OS X verwende. Ich poste es (anstatt eines auf einem Debian-Rechner), weil ich unter OS X unter Macports (und nicht unter Debian) das gleiche Problem 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

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.

Überprüfen Sie /etc/secuiry/limits.conf, um festzustellen, ob Konten feste Beschränkungen für die Anzahl der Anmeldungen haben, und erhöhen Sie diese, dh:

*       hard    maxlogins   0

Überprüfen Sie neben / var / log / messages, wie von Bram erwähnt, auch /var/log/auth.log und fügen Sie alle relevanten Ausgaben ein. Zu viele Informationen sind besser als zu wenig.

Ich bin in der Tat genau diesen Symptomen auf die Weise begegnet, die von @ tom-h zuvor vorgeschlagen wurde ... und die Lösung war sehr einfach.

Um vipwdie passwd-Datei aufzulösen, einfach zu bearbeiten und anzupassen, passen Sie die Shell von / bin / false in / bin / bash oder die Option Ihrer Wahl 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 zum Schutz eines vertraulichen Kontos erfolgen kann. Möglicherweise gelten andere Zugriffsbeschränkungen. Sie sollten wissen, wie wichtig es ist, den Server zu schützen, und sich der Auswirkungen bewusst sein, die es hat, wenn Sie diesen Zugriffstyp zulassen.

Ich hatte ähnliche Probleme mit Ubuntu 16.04 mit LDAP. "ssh -vv ..." zeigte, dass die Kennwortauthentifizierung erfolgreich war, aber dann kam die Meldung: "Die Verbindung zu ... wurde vom Remotehost geschlossen."

Behoben in /etc/ldap.conf in der Konfiguration von "bind_policy".

/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

Gefunden, dass das Problem in /etc/ldap.conf war. Ich habe die bind_policy auf "soft" geändert, sodass nss_ldap bei einem Serverausfall sofort zurückkehrt. Der Standardwert ist "hard_open", der die Verbindung wiederherstellt, wenn das Öffnen der Verbindung zum LDAP-Server fehlgeschlagen ist. Durch Auskommentieren der Zeile "bind_policy soft" wurde die Standardeinstellung wiederhergestellt und das Problem behoben. :-)

Nach langem Suchen fand ich schließlich eine Antwort für den Fall, dass CentOS 7 in einem nicht privilegierten Container ausgeführt wurde.

Kommentieren Sie die session required pam_loginuid.soZeile in der Datei /etc/pam.d/sshd aus und starten Sie den Container neu.

Ich habe diese Lösung unter https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119 gefunden

All dies sind großartige Vorschläge. In meinem Fall war es eine PuTTY-Einstellung, die meine Schmerzen verursachte:

Ich hatte einen Remote-Befehl zum Senden an den Server unter "SSH" -Konfiguration gestellt. Das funktioniert in 99% der Fälle hervorragend. Wenn der Befehl jedoch fehlschlägt, wird die Sitzung nur geschlossen.

Der Befehl??? screen -rd

Funktioniert hervorragend, wenn tatsächlich eine Sitzung fortgesetzt werden muss. Schlägt nach einem Neustart fürchterlich fehl.

Die Lösung:

Verschiebe das nach bashrc / bash_profile.

In meinem Fall wurde es von einem Benutzer ohne Shell auf einem SSH-Server verursacht . Es hat eine sehr einfache Lösung, verwenden Sie einfach den -NSchalter mit Ihrem (Open) SSH-Client.

Von der Manpage :

-N Führt keinen Remote-Befehl aus. Dies ist nützlich, um nur Ports weiterzuleiten.

Ich kann einigen Antworten hier einfach nicht zustimmen. Ein Benutzer mit der Schale /bin/false, /bin/nologinist eine richtige Konfiguration ist es in der Regel für die Nutzer für den SSH - Tunnel nur verwendet verwendet wird , ohne die Möglichkeit zu Anmeldung und führen alle Befehle auf einem SSH - Server. Versuchen Sie also nicht, das Problem auf dem Server zu beheben, sondern verwenden Sie den -NSwitch mit Ihrem SSH-Client.

Stellen Sie sicher, dass /etc/passwddie richtige Shell für den Benutzer vorhanden ist.

Beispielsweise konnte sich der Benutzer ahmadaufgrund fehlender Shell nicht am Server anmelden:

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

Da die Schale Set /bin/falsees bedeutet , dass der Benutzer ahmadnicht eine Schale hat, und das Sie zu beheben müssen sich ändern , /bin/falseum /bin/bashfür bash oder was auch immer andere Muscheln.

Wenn Sie ein Webhosting-Steuerungsfeld verwenden, z. B. Plesk, müssen Sie sicherstellen, dass der Benutzer auf den Server zugreifen kann.

Möglicherweise liegt ein LDAP-Problem vor. Die authconfig zum Konfigurieren von LDAP-, Kerberos- und SMB-Einstellungen wurde ohne Folgendes ausgeführt:

--enablemkhomedir