Linux закрывает соединение после успешного входа

Я работаю на сервере с Debian 5.2.2. Едва имея какие-либо административные знания в Linux, я думаю, что-то напортачил. Я использовал обновления apt-get и apt-get для обновления всего, а затем скачал и установил Apache, PHP и MySQL. Эти инструменты, кажется, работают нормально, но теперь я даже не могу войти на сервер за исключением локальной консоли. Если я пытаюсь войти через GUI или если я пытаюсь войти удаленно через ssh, scp или что-то еще, я немедленно отключаюсь при успешном входе в систему. Другими словами, у него нет проблем с начальным подключением, но когда я ввожу правильное имя пользователя и пароль (для пользователя root или любого пользователя), я отключаюсь. С графическим интерфейсом экран на секунду становится черным, а затем возвращает меня обратно к приглашению входа в систему. С помощью ssh я получаю «соединение с [сервером] закрыто».

Любая помощь приветствуется, и если я смогу дать больше информации, пожалуйста, дайте мне знать. Спасибо за ваше время.

Редактирование:

- Любой пользователь может войти на локальную консоль

- На данный момент у меня нет локального доступа к машине, поэтому все, что я могу сейчас сделать, это ssh. Вот вывод команды ssh -vvv [server] после ввода моего пароля:

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 / messages, как упомянуто Брэмом, также проверьте /var/log/auth.log и вставьте любой соответствующий вывод. Слишком много информации лучше, чем слишком мало.

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

Чтобы решить, просто vipwи отредактируйте файл passwd, настройте shell из / 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 ...» показал, что аутентификация по паролю прошла успешно, но затем появилось сообщение: «Соединение с ... закрыто удаленным хостом».

Исправлено в /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% случаев, однако, когда команда не выполняется, она просто закрывает сеанс.

Команда??? третий экран

Прекрасно работает, когда на самом деле есть сессия, чтобы возобновить. Сбоит ужасно после перезагрузки.

Решение:

переместите это в 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/bashдля Баша или любой других оболочек.

Если вы используете панель управления веб-хостинга, например, Plesk, убедитесь, что у пользователя есть возможность доступа к серверу.

Это может быть проблема LDAP. Authconfig для настройки параметров LDAP, Kerberos и SMB был запущен без

--enablemkhomedir