Zamykanie połączenia z systemem Linux po pomyślnym zalogowaniu

Pracuję na serwerze z Debianem 5.2.2. Ledwo mając wiedzę administracyjną na temat Linuksa, chyba coś spieprzyłem. Użyłem aktualizacji apt-get i apt-get upgrade, aby uzyskać wszystko na bieżąco, a następnie pobrałem i zainstalowałem Apache, PHP i MySQL. Te narzędzia wydają się działać dobrze, ale teraz nie mogę nawet zalogować się na serwer Z WYJĄTKIEM konsoli lokalnej. Jeśli spróbuję zalogować się przez GUI lub jeśli spróbuję zalogować się zdalnie przez ssh, scp lub cokolwiek innego, NATYCHMIAST rozłączę się po pomyślnym zalogowaniu. Innymi słowy, nie ma problemu z początkowym połączeniem, ale kiedy podam prawidłową nazwę użytkownika i hasło (dla użytkownika root lub dowolnego użytkownika), rozłączam się. Dzięki graficznemu interfejsowi ekran na sekundę staje się czarny, a następnie od razu wraca do ekranu logowania. Dzięki ssh otrzymuję „połączenie z [serwerem] zostało zamknięte”.

Każda pomoc jest doceniana, a jeśli istnieje jakikolwiek sposób, w jaki mógłbym podać więcej informacji, proszę dać mi znać. Dziękuję za Twój czas.

Edycje:

- Każdy użytkownik może zalogować się na konsoli lokalnej

- W tej chwili nie mam lokalnego dostępu do maszyny, więc mogę teraz tylko ssh. Oto wynik działania ssh -vvv [serwer] po wprowadzeniu hasła:

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

Istnieje kilka podobnych postów sugerujących, że może to być problem ze spawnem powłoki z powodu niepoprawnych ustawień ścieżki powłoki w /etc/passwd

Aby to sprawdzić, sprawdź, czy ścieżka powłoki użytkownika istnieje i jest wykonywalna;

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

Sprawdź powłokę istnieje:

# 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

sprawdź także, czy powłoka nie jest ustawiona na ani, /sbin/nologinani /bin/false, co również blokowałoby logowanie, nawet po udanym uwierzytelnieniu.

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

Kiedy napotkałem taki problem, nadal miałem ujawnione jedno połączenie / var / log / messages:

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

Edycja vi /etc/init.d/named pozwoliła zmienić sposób montowania / proc, więc błąd nie pojawił się po ponownym uruchomieniu.

Zasadniczo linie

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;

Zostały zmienione na

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

Wskazówka, którą znalazłem na stronie http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

Mój problem polegał na tym, że katalog nazwy użytkownika logowania był niedostępny w tym /homekatalogu. Jeśli więc masz użytkownika o nazwie „testser”, upewnij się, że /home/testuserkatalog jest dostępny. Nauczyłem się tego z /var/log/messagespliku.

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

W sshd_configpliku serwera SSH dodaj następujący wiersz:

UsePAM no

Poniżej znajduje się sshd_configużycie na OS X. Publikuję go (zamiast jednego na maszynie Debiana), ponieważ doświadczyłem tego samego problemu na OS X przy użyciu Macports (a nie Debiana).

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

Jeśli używasz LDAP, zamień każde wystąpienie:

pam_unix_*.so

we wszystkich plikach w /etc/pam.d/ z:

pam_unix.so

Jest to błąd w pakiecie libpam-ldap (przykładowe pliki pam.d), patrz: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

Upewnij się, że system może rozwiązać poprawnie, ssh jest trochę szczególny.

Sprawdź /etc/secuiry/limits.conf, aby sprawdzić, czy jakieś konta mają twarde limity liczby logowań, i zwiększ je, tj .:

*       hard    maxlogins   0

Oprócz / var / log / messages, o których wspomina Bram, sprawdź także /var/log/auth.log i wklej odpowiednie dane wyjściowe. Zbyt dużo informacji jest lepsze niż za mało.

Rzeczywiście napotkałem dokładnie te objawy w sposób sugerowany wcześniej przez @ tom-h ... a rozdzielczość była bardzo prosta.

Aby rozwiązać, po prostu vipwedytuj plik passwd, dostosuj powłokę z / bin / false do / bin / bash lub opcji swoich preferencji.

# 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

Proszę zrozumieć, że w niektórych przypadkach można to zrobić w celu ochrony wrażliwego konta. Mogą obowiązywać inne ograniczenia dostępu. Powinieneś wiedzieć, jak ważna jest ochrona serwera i być świadomym konsekwencji zezwolenia na tego typu dostęp do niego.

Miałem podobne problemy z Ubuntu 16.04 z LDAP. „ssh -vv ...” pokazał, że uwierzytelnienie hasłem powiodło się, ale potem nadeszła wiadomość: „Połączenie z ... zostało zamknięte przez zdalny host”.

Naprawiono w /etc/ldap.conf w konfiguracji „bind_policy”.

/var/log/auth.log pokazał:

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

Stwierdzono, że problem występuje w /etc/ldap.conf. Zmieniłem bind_policy na „soft”, więc nss_ldap natychmiast zwraca awarię serwera. Domyślnie jest to „hard_open”, które łączy się ponownie, jeśli otwarcie połączenia z serwerem LDAP nie powiodło się. Komentowanie wiersza „bind_policy soft” zmieniło go z powrotem na domyślne i rozwiązało problem. :-)

Po wielu poszukiwaniach w końcu znalazłem odpowiedź w przypadku CentOS 7 działającego w nieuprzywilejowanym kontenerze.

Skomentuj session required pam_loginuid.sowiersz w pliku /etc/pam.d/sshd, a następnie ponownie uruchom kontener.

Znalazłem to rozwiązanie na https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119

Wszystko to są świetne sugestie. W moim przypadku było to ustawienie PuTTY powodujące mój ból:

Wysłałem zdalne polecenie, aby wysłać na serwer w konfiguracji „SSH”. Co działa świetnie w 99% przypadków, jednak gdy polecenie się nie powiedzie, po prostu zamyka sesję.

Komenda??? screen -rd

Działa świetnie, gdy sesja jest wznawiana. Zawodzi strasznie po ponownym uruchomieniu.

Rozwiązanie:

przenieś to do bashrc / bash_profile.

W moim przypadku było to spowodowane przez użytkownika bez powłoki na serwerze SSH . Ma bardzo łatwą naprawę, wystarczy użyć -Nprzełącznika z (otwartym) klientem SSH.

Od strony man :

-N Nie wykonuj polecenia zdalnego. Jest to przydatne tylko w przypadku portów przekierowujących.

Po prostu nie mogę zgodzić się z niektórymi odpowiedziami tutaj. Użytkownik z muszli /bin/false, /bin/nologinjest właściwa konfiguracja, to zwykle stosowane dla użytkowników wykorzystywane tylko dla tuneli SSH, bez możliwości, aby zalogować się i wykonać wszelkie polecenia na serwerze SSH. Więc nie próbuj go „naprawiać” na serwerze, wystarczy użyć -Nprzełącznika z klientem SSH.

Upewnij się, że /etc/passwdma poprawną powłokę dla użytkownika.

Na przykład użytkownik ahmadnie mógł zalogować się do serwera z powodu braku powłoki:

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

Ponieważ zbiór muszli na /bin/falseniej oznacza, że użytkownik ahmadnie posiada powłokę, i naprawić to trzeba zmienić /bin/false, aby /bin/bashdla bash lub cokolwiek innych skorup.

Jeśli korzystasz z panelu kontrolnego hostingu, np. Plesk, upewnij się, że użytkownik ma dostęp do serwera.

Może to być problem z LDAP. Authconfig do skonfigurowania ustawień LDAP, Kerberos i SMB został uruchomiony bez,

--enablemkhomedir