Linux завершує з'єднання після успішного входу

Я працюю на сервері з Debian 5.2.2. Ледь не маючи адміністративних знань з Linux, я думаю, що я щось накрутив. Я використовував apt-get update та apt-get upgrade, щоб оновлювати все, а потім завантажив та встановив Apache, PHP та MySQL. Ці інструменти, здається, працюють нормально, але тепер я навіть не можу увійти на сервер ВСІМО через локальну консоль. Якщо я спробую увійти через графічний інтерфейс або якщо я намагаюсь увійти дистанційно через ssh, scp чи щось інше, я негайно відключаюсь після успішного входу. Іншими словами, це не має проблем з початковим з'єднанням, але коли я ввожу правильне ім’я користувача та пароль (для root або будь-якого користувача), я відключаюсь. За допомогою графічного інтерфейсу екран на секунду затьмарюється, а потім повертає мене прямо до запиту для входу. З ssh я отримую "з'єднання з [сервером] закрито."

Будь-яка допомога вдячна, і якщо є якийсь спосіб я можу дати більше інформації, будь ласка, дайте мені знати. Спасибі за ваш час.

Зміни:

- Будь-який користувач може увійти на локальну консоль

- На даний момент я не маю локального доступу до машини, тому все, що я зараз можу зробити, - це ssh. Ось вихід ssh -vvv [сервера] після введення пароля:

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

Є кілька подібних публікацій, які дозволяють припустити, що це може бути проблемою з нерестуванням оболонки через неправильні налаштування шляху оболонки в /etc/passwd

Щоб перевірити це, визначте, що ваш шлях до оболонки користувача існує та виконується;

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

Перевірка оболонки існує:

# 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

також переконайтесь, що оболонці не встановлено жодного /sbin/nologinабо /bin/false, що також блокує вхід, навіть при успішній аутентифікації.

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

Коли я зіткнувся з такою проблемою, у мене все ще було відкрито одне з'єднання / var / log / messages:

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

Редагування vi /etc/init.d/named дозволило змінити спосіб монтажу / proc, тому помилка не відбулася після перезавантаження.

В основному лінії

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;

Були змінені на

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

Пораду, яку я знайшов на веб- сайті http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

Моя проблема полягала в тому, що вхід у каталог користувачів імені користувача недоступний /home. Тож якщо у вас є користувач під назвою 'testuser', переконайтеся, що /home/testuserкаталог доступний. Дізналися про це з /var/log/messagesфайлу.

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

У sshd_configфайл вашого сервера SSH додайте такий рядок:

UsePAM no

Нижче наведено те, що sshd_configя використовую в OS X. Я публікую його (а не одну на машині Debian), оскільки я відчував ту ж проблему в OS X за допомогою Macports (а не Debian).

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

Якщо ви використовуєте LDAP, замініть кожне виникнення:

pam_unix_*.so

у всіх файлах /etc/pam.d/ з:

pam_unix.so

Це помилка в пакеті libpam-ldap (наприклад, файли pam.d), див .: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

Переконайтеся, що система може правильно вирішувати, ssh трохи про це.

Перевірте /etc/secuiry/limits.conf, щоб побачити, чи є якісь акаунти жорсткі обмеження щодо кількості вхідних даних, і збільшити їх, тобто:

*       hard    maxlogins   0

Окрім / var / log / повідомлень, як згадував Bram, також перевірте /var/log/auth.log та будь-ласка, вставте будь-який відповідний вихід. Занадто багато інформації краще, ніж занадто мало.

Я справді стикався саме з цими симптомами в моді, запропонованій @ tom-h раніше ... і резолюція була дуже однозначною.

Щоб вирішити, просто vipwі відредагуйте файл passwd, відрегулюйте оболонку з / bin / false в / bin / bash або опцію за вашим уподобанням.

# 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

Зверніть увагу, що в деяких випадках це може бути зроблено для захисту конфіденційного облікового запису. Можуть бути інші обмеження доступу. Ви повинні знати важливість захисту сервера і знати про наслідки дозволу такого типу доступу до нього.

У мене були подібні проблеми з Ubuntu 16.04 з LDAP. "ssh -vv ..." показав, що автентифікація пароля вдалася, але потім з'явився msg: "Підключення до ... закрите віддаленим хостом."

Виправлено в /etc/ldap.conf у конфігурації "bind_policy".

/var/log/auth.log показав:

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

Виявлено, що проблема була в /etc/ldap.conf. Я змінив bind_policy на "soft", тому nss_ldap негайно повертається після відмови сервера. За замовчуванням - "hard_open", який знову підключається, якщо не вдалося відкрити з'єднання з сервером LDAP. Коментуючи рядок "bind_policy soft" повернув його до типового та вирішив проблему. :-)

Після багатьох пошуків я нарешті знайшов відповідь у випадку, коли CentOS 7 працює в непривілейованому контейнері.

Прокоментуйте session required pam_loginuid.soрядок у файлі /etc/pam.d/sshd, а потім перезавантажте контейнер.

Я знайшов це рішення на https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119

Все це чудові пропозиції. У моєму випадку саме біль «PuTTY» викликав мій біль:

Я поставив віддалену команду для відправки на сервер під конфігурацією "SSH". Що працює чудово у 99% часу, однак, коли команда не працює, вона просто закриває сеанс.

Команда ??? екран -rd

Чудово працює, коли насправді є сеанс для відновлення. Жахливо виходить з ладу після перезавантаження.

Рішення:

перемістіть його до bashrc / bash_profile.

У моєму випадку це було викликано користувачем без оболонки на сервері SSH . Це дуже просте виправлення, просто використовуйте -Nкомутатор разом із вашим (Відкритим) SSH клієнтом.

На чоловіковій сторінці :

-N Не виконуйте віддалену команду. Це корисно лише для переадресації портів.

Я просто не можу погодитися з деякими відповідями тут. Користувач із оболонкою /bin/false, /bin/nologinмає правильну конфігурацію, зазвичай використовується для користувачів, які використовуються лише для тунелів SSH, без можливості входу та виконання будь-яких команд на сервері SSH. Тому не намагайтеся "виправити" це на сервері, просто використовуйте -Nкомутатор разом із вашим клієнтом SSH.

Переконайтеся, що в /etc/passwdньому є правильна оболонка для користувача.

Наприклад, користувач ahmadне зміг увійти на сервер через відсутність оболонки:

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

Оскільки оболонка, встановлена ​​на /bin/falseнього, означає, що у користувача ahmadнемає оболонки, і щоб виправити це, вам потрібно змінити /bin/falseна /bin/bashbash або будь-які інші оболонки.

Якщо ви використовуєте панель управління веб-хостингом, наприклад, Plesk, переконайтеся, що користувач має можливість доступу до сервера.

Це може бути проблема LDAP. Authconfig для налаштування параметрів LDAP, Kerberos та SMB виконується без,

--енаблемхомедір