it-swarm.com.de

Linux schließt die Verbindung nach erfolgreicher Anmeldung

Ich arbeite an einem Server mit Debian 5.2.2. Ich habe kaum administrative Kenntnisse mit Linux und glaube, ich habe etwas vermasselt. 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 einmal über die lokale Konsole beim Server anmelden. Wenn ich versuche, mich über die GUI anzumelden, oder wenn ich versuche, mich remote über ssh, scp oder irgendetwas anderes anzumelden, werde ich bei erfolgreicher Anmeldung SOFORT 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 Benutzer) eingebe, wird die Verbindung getrennt. Mit der GUI wird der Bildschirm für eine Sekunde schwarz und bringt mich dann direkt zurück zur Anmeldeaufforderung. Mit ssh bekomme ich "Verbindung zu [Server] geschlossen". Ich habe WinSCP ausprobiert und erhalte die Meldung "Die Verbindung wurde unerwartet geschlossen. Der Server hat den Status 254 zum Beenden des Befehls gesendet."

Jede Hilfe wird geschätzt, und wenn es eine Möglichkeit gibt, weitere Informationen zu geben, 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, daher kann ich jetzt nur ssh tun. 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
23
rymo

Es gibt einige ähnliche Beiträge, die darauf hinweisen, dass dies aufgrund falscher Einstellungen für den Shell-Pfad in /etc/passwd Ein Problem beim Laichen einer Shell sein könnte.

Um dies zu überprüfen, stellen Sie fest, 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

Check 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 weder auf /sbin/nologin noch auf /bin/false eingestellt ist, wodurch die Anmeldung auch bei erfolgreicher Authentifizierung blockiert wird.

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/[email protected]/msg04460.html

27
Tom H

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

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

Durch Bearbeiten von vi /etc/init.d/named konnte die Art und Weise geändert werden, in der/proc bereitgestellt 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;

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

4
Heinrich Krebs

Mein Problem war, dass das Login-Benutzernamenverzeichnis im Verzeichnis /home Nicht verfügbar war. Wenn Sie also einen Benutzer namens 'testuser' haben, stellen Sie sicher, dass das Verzeichnis /home/testuser Verfügbar ist. Das habe ich aus der Datei /var/log/messages Gelernt.

4
grit
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 Datei sshd_config Ihres SSH-Servers die folgende Zeile hinzu:

UsePAM no

Unten ist der sshd_config, Den ich unter OS X verwende. Ich poste ihn (anstatt einen auf einem Debian-Computer), weil ich unter OS X mit 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
3
user145545

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 dabei etwas Besonderes.

Überprüfen Sie /etc/secuiry/limits.conf, um festzustellen, ob für Konten die Anzahl der Anmeldungen fest ist, und erhöhen Sie diese, d. H.:

*       hard    maxlogins   0

Überprüfen Sie zusätzlich zu/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.

2
aseq

Ich habe in der Tat genau diese Symptome auf die von @ tom-h zuvor vorgeschlagene Weise festgestellt ... und die Lösung war sehr einfach.

Zum Auflösen einfach vipw und bearbeiten Sie die passwd-Datei, passen Sie die Shell von/bin/false auf/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 sensiblen Kontos erfolgen kann. Möglicherweise sind andere Zugriffsbeschränkungen vorhanden. Sie sollten wissen, wie wichtig es ist, den Server zu schützen, und sich der Auswirkungen bewusst sein, die sich aus dem Zulassen dieser Art des Zugriffs auf den Server ergeben.

1
Adam John

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

Kommentieren Sie das session required pam_loginuid.so Zeile in der Datei /etc/pam.d/sshd und starten Sie den Container neu.

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

1
Steve Jorgensen

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

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

Es wurde festgestellt, dass das Problem in /etc/ldap.conf liegt. Ich habe die bind_policy in "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. :-)

1
Namo Amituofo

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 eingegeben. Was in 99% der Fälle sehr gut funktioniert. Wenn der Befehl jedoch fehlschlägt, wird die Sitzung nur geschlossen.

Der Befehl??? Bildschirm -rd

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

Die Lösung:

verschieben Sie das nach bashrc/bash_profile.

0
Dave

Ich bin gerade auf dieses Problem gestoßen (speziell für SFTP, aber nicht für SSH, wo ich ohne Probleme eine Verbindung herstellen konnte) und keine der Lösungen hier hat für mich funktioniert. In meinem Fall lag es daran, dass in ~/.ssh/ Zu viele SSH-Schlüssel (IdentityFiles) vorhanden waren. Es scheint, dass wenn Sie keinen Host-Eintrag in ~/.ssh/config Für den Host haben, zu dem Sie eine Verbindung mit dem richtigen Schlüssel herstellen möchten, alle Ihre Schlüssel einzeln gesendet werden. Ich hatte mehr als 6 Schlüssel und sicher ist der Standardwert MaxAuthTries 6 (zumindest in Ubuntu).

Die Lösung bestand darin, den /etc/ssh/sshd_config Des Servers zu bearbeiten und MaxAuthTries zu erhöhen. Ich habe meine auf 10 gesetzt.

#MaxAuthTries 6
MaxAuthTries 10

(Oder fügen Sie einfach einen Host-Eintrag mit dem richtigen Schlüssel hinzu. In diesem speziellen Fall versuche ich, mich ohne Verwendung eines Schlüssels anzumelden.).

0
insaner

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 die -N Wechseln Sie mit Ihrem (offenen) SSH-Client.

Aus der Manpage :

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

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

Stellen Sie sicher, dass /etc/passwd Die richtige Shell für den Benutzer hat.

Beispielsweise konnte sich der Benutzer ahmad aufgrund fehlender Shell nicht beim Server anmelden:

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

Da die Shell auf /bin/false Gesetzt ist, bedeutet dies, dass der Benutzer ahmad keine Shell hat. Um dies zu beheben, müssen Sie /bin/false Für bash in /bin/bash Ändern oder was auch immer andere Muscheln.

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

0
Ahmad