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

Есть несколько похожих сообщений, предполагающих, что это может быть проблемой с созданием оболочки из-за неправильных настроек пути к оболочке в /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

Моя проблема заключалась в том, что каталог имени пользователя для входа был недоступен в /home каталог. Поэтому, если у вас есть пользователь с именем testuser, убедитесь, что /home/testuser каталог доступен. Узнал об этом из /var/log/messages файл.

Когда я столкнулся с такой проблемой, у меня все еще было открыто одно соединение / 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

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

На вашем SSH-сервере sshd_config файл, добавьте следующую строку:

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

Команда??? экран -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/bash для bash или любых других оболочек.

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

Я только что столкнулся с этой проблемой (особенно для sftp, но не ssh, где я мог подключиться без проблем), и ни одно из решений здесь не помогло мне. В моем случае это произошло из-за слишком большого количества ключей ssh ​​(IdentityFile) в ~/.ssh/. Кажется, что когда у вас нет записи о хосте в ~/.ssh/config для хоста, к которому вы пытаетесь подключиться с правильным ключом, он просто отправляет все ваши ключи один за другим. У меня было более 6 ключей, и, конечно же, по умолчанию MaxAuthTries равно 6 (по крайней мере, в Ubuntu).

Решением было отредактировать серверный /etc/ssh/sshd_config и увеличить MaxAuthTries. Я установил 10.

#MaxAuthTries 6
MaxAuthTries 10

(Или, конечно, просто добавьте запись хоста с правильным ключом - в этом конкретном случае я пытаюсь войти в систему без использования ключа).

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

--энаблемхомедир