Conexão de fechamento do Linux após o login bem-sucedido

Question

Estou trabalhando em um servidor com o Debian 5.2.2. Mal tendo qualquer conhecimento administrativo com o Linux, acho que estraguei alguma coisa. Eu usei o apt-get update e o apt-get upgrade para atualizar tudo e depois baixei e instalei o Apache, PHP e MySQL. Essas ferramentas parecem funcionar bem, mas agora não consigo nem mesmo fazer o login no servidor EXCETO via console local. Se eu tentar fazer o login através da GUI ou se eu tentar fazer o login remotamente via ssh, scp ou qualquer outra coisa, eu me desconecto IMEDIATAMENTE após o login bem-sucedido. Em outras palavras, não há problema com a conexão inicial, mas quando eu coloco o nome de usuário e senha corretos (root ou qualquer usuário), eu me desconecto. Com a GUI, a tela fica preta por um segundo e depois me coloca de volta no prompt de login. Com ssh, eu recebo "conexão para [servidor] fechado". Eu tentei WinSCP e recebo "Conexão foi fechada inesperadamente. Servidor enviado comando status de saída 254."

Qualquer ajuda é apreciada, e se houver alguma maneira de dar mais informações, por favor me avise. Obrigado pelo seu tempo.

Edições:

- Qualquer usuário pode fazer o login no console local

- No momento não tenho acesso local à máquina, então tudo que posso fazer agora é o ssh. Aqui está a saída de ssh -vvv [server] depois de inserir minha senha:

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

    

Answer 1

Há alguns posts semelhantes sugerindo que isso pode ser um problema com a geração de um shell devido a configurações incorretas para o caminho do shell em /etc/passwd

Para verificar isso, determine se o caminho do shell do usuário existe e é executável;

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

Verifique se o shell existe:

# 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

também, verifique se o shell não está definido como /sbin/nologin ou /bin/false , o que também bloqueia o login, mesmo com uma autenticação bem-sucedida.

link
link
link

    

Answer 2

Meu problema era que o diretório de nome de usuário de login não estava disponível no diretório /home . Portanto, se você tiver um usuário chamado 'testuser', verifique se o diretório /home/testuser está disponível. Aprendi que a partir do arquivo /var/log/messages .

    

Answer 3

Quando encontrei um problema desse tipo, ainda tinha uma conexão aberta / var / log / messages revelado:

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

Editar vi /etc/init.d/named permissão para mudar o caminho / proc foi montado, então o erro não após uma reinicialização.

Basicamente as linhas

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;

Foram alterados para

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

Uma dica que encontrei no link

    

Answer 4

Se você estiver usando o LDAP, substitua todas as ocorrências de:

pam_unix_*.so

em todos os arquivos em /etc/pam.d/ com:

pam_unix.so

Este é um bug no pacote libpam-ldap (por exemplo, arquivos pam.d), veja: link

Certifique-se de que o sistema possa ser resolvido corretamente. O ssh é um pouco específico sobre isso.

Verifique o /etc/secuiry/limits.conf para ver se as contas têm limites rígidos na quantidade de logins e aumentá-las, por exemplo:

*       hard    maxlogins   0

Além de / var / log / messages como mencionado por Bram, verifique também /var/log/auth.log e cole qualquer saída relevante. Muita informação é melhor do que muito pouco.

    

Answer 5

Eu realmente encontrei exatamente esses sintomas da maneira sugerida por @ tom-h mais cedo ... e a resolução foi muito direta.

Para resolver, basta vipw e editar o arquivo passwd, ajustar o shell de / bin / false para / bin / bash ou a opção de sua preferência.

# 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

Por favor, entenda que, em alguns casos, isso pode ser feito para proteger uma conta confidencial. Pode haver outras restrições de acesso em vigor. Você deve saber a importância de proteger o servidor e estar ciente das implicações de permitir esse tipo de acesso a ele.

    

Answer 6

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

No arquivo sshd_config do seu servidor SSH, adicione a seguinte linha:

UsePAM no

Abaixo está o sshd_config que eu uso no OS X. Eu estou postando (em vez de um em uma máquina Debian) porque eu experimentei o mesmo problema no OS X usando Macports (e não 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

    

Answer 7

Todas essas são ótimas sugestões. No meu caso, foi uma configuração PuTTY que causou minha dor:

Eu coloquei um comando remoto para enviar para o servidor na configuração "SSH". O que funciona muito bem 99% do tempo, no entanto, quando o comando falha, ele apenas fecha a sessão.

O comando ??? tela -rd

Funciona muito bem quando realmente há uma sessão para continuar. Falha horrivelmente depois de um reinício.

A solução:

mova isso para bashrc / bash_profile.

    

Answer 8

No meu caso, foi causado por um usuário sem um shell em um servidor SSH . Ele tem uma correção muito fácil, basta usar a opção -N com seu cliente SSH (Open).

Na página de manual :

-N Do not execute a remote command. This is useful for just forwarding ports.

Eu simplesmente não posso concordar com algumas das respostas aqui. Um usuário com o shell /bin/false , /bin/nologin é uma configuração adequada, geralmente é usado para usuários usados apenas para túneis SSH, sem a possibilidade de efetuar login e executar qualquer comando em um servidor SSH. Portanto, não tente "consertar" isso no servidor, apenas use a opção -N com seu cliente SSH.

    

Answer 9

Certifique-se de que /etc/passwd tenha o shell correto para o usuário.

Por exemplo, o usuário ahmad não pôde acessar o servidor devido à falta do shell:

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

Como o shell definido como /bin/false , significa que o usuário ahmad não tem um shell e, para corrigir isso, você precisa alterar /bin/false para /bin/bash para bash ou qualquer outro shells.

Se você estiver usando um painel de controle de hospedagem na Web, por exemplo, Plesk, certifique-se de que o usuário tenha a capacidade de acessar o servidor.

    

Answer 10

Eu tive problemas semelhantes com o Ubuntu 16.04 com o LDAP. "ssh -vv ..." mostrou que a autenticação por senha foi bem-sucedida, mas então veio a mensagem: "Conexão para ... fechada pelo host remoto".

Corrigido em /etc/ldap.conf na configuração de "bind_policy".

/var/log/auth.log mostrou:

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

Descobrimos que o problema estava no /etc/ldap.conf. Eu mudei o bind_policy para "soft", então nss_ldap retorna imediatamente na falha do servidor. O padrão é "hard_open", que é reconectado se a abertura da conexão com o servidor LDAP falhar. Comentando a linha "bind_policy soft" mudou de volta para o padrão, e resolveu o problema. : -)