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

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

Qualquer ajuda é apreciada e, se houver alguma maneira de fornecer mais informações, entre em contato. Obrigado pelo seu tempo.

Edições:

- Qualquer usuário pode fazer login no console local

- No momento, não tenho acesso local à máquina, então tudo o que posso fazer agora é ssh. Aqui está a saída do 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

Existem algumas postagens semelhantes sugerindo que isso pode ser um problema ao gerar um shell devido a configurações incorretas do 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

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

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

Quando encontrei esse problema, eu ainda tinha uma conexão aberta / var / log / messages revelada:

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

A edição de vi /etc/init.d/named permitiu alterar a maneira como o / proc foi montado, portanto, o erro não ocorreu 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 em http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

Meu problema foi que o diretório de nome de usuário de login não estava disponível no /homediretório. Portanto, se você tiver um usuário chamado 'testuser', verifique se o /home/testuserdiretório está disponível. Aprendi isso com o /var/log/messagesarquivo.

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 sshd_configarquivo do seu servidor SSH , adicione a seguinte linha:

UsePAM no

Abaixo está o que sshd_configeu uso no OS X. Estou publicando (em vez de um em uma máquina Debian) porque tive o mesmo problema no OS X usando Macports (e não 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

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

pam_unix_*.so

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

pam_unix.so

Este é um erro no pacote libpam-ldap (por exemplo, arquivos pam.d), consulte: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

Verifique se o sistema pode resolver corretamente, ssh é um pouco específico sobre isso.

Verifique /etc/secuiry/limits.conf para ver se alguma conta tem limites rígidos na quantidade de logins e aumente-os, ou seja:

*       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 pouca.

Na verdade, eu encontrei exatamente esses sintomas da maneira sugerida por @ tom-h anteriormente ... e a resolução foi muito direta.

Para resolver, simplesmente vipwe edite o arquivo passwd, ajuste 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. Você deve saber a importância de proteger o servidor e estar ciente das implicações de permitir esse tipo de acesso a ele.

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

Corrigido no /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

Constatou que o problema estava no /etc/ldap.conf. Eu mudei o bind_policy para "soft", para que o nss_ldap retorne imediatamente na falha do servidor. O padrão é "hard_open", que reconecta se a abertura da conexão com o servidor LDAP falhar. Comentar a linha "bind_policy soft" voltou ao padrão e resolveu o problema. :-)

Depois de muita pesquisa, finalmente encontrei uma resposta no caso do CentOS 7 rodando em um contêiner sem privilégios.

Comente a session required pam_loginuid.solinha no arquivo /etc/pam.d/sshd e reinicie o contêiner.

Encontrei esta solução em https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119

Todas essas são ótimas sugestões. No meu caso, foi um cenário PuTTY que causou minha dor:

Eu havia colocado um comando remoto para enviar ao servidor na configuração "SSH". O que funciona muito bem 99% das vezes, no entanto, quando o comando falha, ele fecha a sessão.

O comando??? tela -rd

Funciona muito bem quando há realmente uma sessão para retomar. Falha horrivelmente após uma reinicialização.

A solução:

mova isso para bashrc / bash_profile.

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

Na página do manual :

-N Não execute um comando remoto. Isso é útil apenas para encaminhamento de portas.

Eu simplesmente não posso concordar com algumas das respostas aqui. Um usuário com a casca /bin/false, /bin/nologiné uma configuração adequada, é geralmente usado para usuários usados só para túneis SSH, sem a possibilidade de login e executar todos os comandos em um servidor SSH. Portanto, não tente "consertá-lo" no servidor, basta usar o -Nswitch com seu cliente SSH.

Verifique se /etc/passwdo shell está correto para o usuário.

Por exemplo, o usuário ahmadnão pôde efetuar login no servidor devido à falta do shell:

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

Como o conjunto de shell para /bin/falseque significa que o usuário ahmadnão tem uma concha, e de corrigir isso você tem que mudar /bin/falsepara /bin/bashpara o bash ou qualquer outro conchas.

Se você estiver usando um painel de controle de hospedagem na web, por exemplo, o Plesk, verifique se o usuário pode acessar o servidor.

Pode ser um problema LDAP. O authconfig para definir as configurações LDAP, Kerberos e SMB foi executado sem,

--enablemkhomedir