Linux-Verbindung wird nach erfolgreicher Anmeldung geschlossen


23

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

5
Linux ist ein Kernel, kein Betriebssystem. Es gibt keine Kernel-Version 5.2.2. Welche Distribution verwenden Sie?
Sven

2
Melden Sie sich über die Konsole an und aktivieren Sie /var/log/messagesund, /car/log/securewenn Sie versuchen, sich remote anzumelden. Versuchen Sie, sich mit anzumelden, ssh -vvv <servername>damit Sie sehen können, was falsch läuft. dmesgDie Ausgabe kann ebenfalls nützlich sein, Sie müssen jedoch nur relevante Teile zuschneiden und veröffentlichen. Können Sie sich mit einem beliebigen Benutzerkonto auf der lokalen Konsole oder nur mit root anmelden? Läuft der SSH-Dämon ( ps auxwww|grep ssh)?
Bram

Antworten:


24

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


Dies war in der Tat mein Problem, bei einer neuen Cygwin-Installation musste der von der Installation erstellte Benutzer den Pfad / bin / false angeben. Das Ändern in / bin / bash behebt das Problem. Vielen Dank!
Mitch Kent

1
Nach meiner Erfahrung ist es ratsam, die Shell beim Erstellen des Benutzers anzugeben. Die Standardeinstellung variiert von dist zu dist.
MetalGodwin

4

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


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

Was ist das Äquivalent zu CentOS 7, das systemd anstelle von SysV verwendet?
Steve Jorgensen

4

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 .


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

3
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

1
UsePAM = yes ist das Problem in meinem centos7 / i686 LXD-Image. Sobald 'no' eingestellt ist, funktionieren die SSH-Anmeldungen wieder. Es gibt jedoch einen Hinweis in sshd_config: "WARNUNG: 'UsePAM no' wird in Red Hat Enterprise Linux nicht unterstützt und kann verschiedene Probleme verursachen." Wenn jemand weiß, was das genau bedeutet, werfen Sie bitte etwas Licht auf.
ILIV

Als ich versuchte, zu UsePAM = no zu wechseln, wurde ich aufgefordert, ein Passwort einzugeben, obwohl ich mich mit einem RSA-Schlüssel authentifizieren sollte.
Steve Jorgensen

2

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.


1

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.


1

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. :-)



0

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.


0

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.


0

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.


-1

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

--enablemkhomedir


Hallo, versuchen Sie, andere Fragen zu beantworten: OP spricht über Debian 5, das für die Produktion völlig veraltet ist
bgtvfr
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.