Tempo de espera longo no login

Quando entro no meu servidor, recebo o seguinte:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

então eu devo esperar por 5 segundos e então está pronto ...

wolfy@ubuntu-server:~$

Esse tempo de espera é normal ou devo fazer algo para "reparar" isso?

Isso geralmente é o resultado da pam_motdregeneração do /etc/motdarquivo. Você pode verificar os scripts individuais /etc/update-motd.dpara ver se algo está especialmente lento.

Eu tenho os mesmos problemas com 10.04 (LTS).

Quando executo meu ssh -vvv, ele morre em:

debug1: Entering interactive session.

Estendendo esta resposta.

Eu consegui reiniciar o servidor remotamente e habilitei o loggin DEBUG. Também aproveitou esta oportunidade para permanecer conectado e observar outras tentativas de login. Aqui está o que acontece. O cliente se conecta e está autorizado e trava na mensagem acima.

No servidor, a lista de processos mostra o seguinte:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

Posso executar /usr/bin/python /usr/bin/landscape-sysinfomuito bem enquanto estou logado, mas, por algum motivo, não consigo descobrir por que ele interrompe o processo de login. Quando eu encerro o processo, o login continua no prompt e é bem - sucedido .

Este não parece ser um problema ssh (d), é mais relacionado ao update-motdcenário. Eu desinstalei o update-motdpacote, mas parece que o /etc/update-motddiretório persiste e os scripts ainda são executados - causando a interrupção do processo.

Depurando isso ainda mais:

Acontece que o /etc/update-motd.d/diretório realmente não pertence ao pacote update-motd, parece ter sido acionado pela autenticação do pam através do sshd.

Eu pareço ter acertado!

Desativado pam_motd nos seguintes arquivos:

• /etc/pam.d/sshd
• /etc/pam.d/login

Mais um:

apt-get purge landscape-client landscape-common

Estes parecem ajudar até certo ponto. No entanto, ele apenas remove o script incorreto /etc/update-motd.d/e nem exclui todos os scripts nesse diretório, nem é eliminado pam_motd.

Em geral, não encontrei nenhuma maneira de desabilitar pam_motdcompletamente porque parece, o que quer que faça - diminui o processo de login até certo ponto. Não bloqueia como o script landscape-common, mas é mais lento.

Relatório de bug sobre este problema:

• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

Soluções alternativas a partir daí:

Você está certo de que a capacidade de fazer login é mais importante do que apresentar um motivo. Se esse comportamento for um problema para você, existem várias maneiras de desabilitá-lo:

• comente a linha 'pam_motd' /etc/pam.d/sshdse você não quiser exibir um motd.
• exclua o conteúdo do /etc/update-motd.ddiretório.
• chmod -x os scripts nos /etc/update-motd.dquais você não deseja executar.

Solução encontrada finalmente:

1. sudo apt-get remove landscape-client landscape-common
2. linha de comentário session optional pam_motd.so em /etc/pam.d/logine/etc/pam.d/sshd

Agora o login é IMEDIATO!

Na sua descrição, parece mais um problema de rede. Diagnosticar:

• Execute ssh com o parâmetro -v para ser detalhado.
• Tente executar um ping no servidor SSH ao qual você está se conectando e veja se isso também trava ao mesmo tempo.
• Tente outro tipo de transferência para o mesmo servidor. Por exemplo, wget com o parâmetro --limit-rate para buscar um arquivo por HTTP e fazer com que demore o suficiente para que ele possa desencadear o comportamento "travado".
• Veja se ele trava apenas quando está ocioso ou mesmo se você está fazendo algo no momento. Se parar enquanto estiver ocioso, os diagnósticos -v provavelmente o informarão; nesse caso, o conselho para usar o keepalive pode ajudar (ssh -o "TCPKeepAlive yes")

Se você conseguir se conectar bem ao Windows e ao PuTTY, provavelmente não será um problema no lado do servidor.

Se PermitEmptyPassworde UsePAMsão ambos habilitado, o servidor OpenSSH sempre tentativas de autenticação com uma senha nula, que toma como um sinal de que nenhuma autenticação é necessária para a conta em questão. Isso é feito assim que o processo de autenticação é iniciado, nos dois protocolos, e não em resposta a nenhuma solicitação de autenticação "real" do cliente. O OpenSSH permitirá apenas esse acesso se o sinalizador sshd_config PermitEmptyPasswordestiver definido; infelizmente, da maneira como o código é escrito, ele executa o teste de senha em qualquer caso e, portanto, aparece no PAM como uma falha.

Então: desative PermitEmptyPasswordou UsePAM, mas lembre-se: sem o PAM, você não poderá fazer login sem uma chave.

Referência: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

Acho que quando você faz login, o ubuntu executa um ou mais desses arquivos:

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

Você pode ver o que há neles e talvez até tentar executá-los para ver o que está demorando tanto.

Na minha experiência limitada, quando o putty funciona, mas o Linux, o Ubuntu, nesse caso, não funciona, ele geralmente é mantido vivo. Problemas de rede ou servidor afetariam o SO do cliente.

Você pode usar a opção keep alive acima na linha de comando, mas é meio tedioso digitar.

Mais fácil de editar alguns arquivos de configuração.

Se você possui root accesse deseja ativá-lo automaticamente para todos os usuários, edite /etc/ssh/ssh_config, adicione

KeepAlive yes
ServerAliveInterval 120

Se você não possui acesso root ou para habilitá-lo para um único usuário, edite ~/.ssh/confige adicione as mesmas duas linhas.

Verifique os logs do sistema em / var / log, você pode encontrar uma mensagem com o erro / tempo limite relacionado.

Se você também tiver um tempo, espere antes

Editar /etc/sshd_config

e defina (ou adicione)

UseDNS no

ou adicione seu ip /etc/hostsse for um local estático

Você pode tentar monitorar os processos em execução enquanto estiver efetuando login no servidor a partir de uma conexão já conectada (ou de um console diferente). Há uma chance de identificar quais processos são os mais ativos ou que utilizam mais CPU naquele momento.

Abaixo está um método possível:

1. Tente fazer login em outro console.
2. Corra toppara lá para ver o que acontece.
3. Faça login no 1º console.

Observe que, se o atraso não for causado por algum cálculo intensivo da CPU, você não encontrará nada fora do lugar. Nesse caso, o problema pode estar ligado à E / S (aguardando alguma leitura / gravação de disco ou resposta de rede).