Isso geralmente é o resultado de pam_motd gerar novamente o arquivo /etc/motd . Você pode verificar os scripts individuais em /etc/update-motd.d para ver se algo está muito lento.
Quando eu faço login no meu servidor, recebo isso:
No mail.
Last login: Fri Nov 5 14:22:45 2010...
então devo esperar por 5 segundos e depois pronto ...
wolfy@ubuntu-server:~$
Este tempo de espera é normal ou devo fazer algo para "reparar" isso?
Isso geralmente é o resultado de pam_motd gerar novamente o arquivo /etc/motd . Você pode verificar os scripts individuais em /etc/update-motd.d para ver se algo está muito lento.
Eu tenho os mesmos problemas com 10.04 (LTS).
Quando executo meu ssh com -vvv , ele morre em:
debug1: Entering interactive session.
Estendendo esta resposta.
Consegui reinicializar o servidor remotamente e habilitei o loggin DEBUG. Também aproveite esta oportunidade para permanecer logado e observar outras tentativas de login. Aqui está o que acontece. O cliente se conecta e é autorizado e trava na mensagem acima.
No servidor, a lista de processos mostra isso:
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>
Eu posso executar /usr/bin/python /usr/bin/landscape-sysinfo bem enquanto estou logado, mas por alguma razão, não consigo entender por que isso atrasa o processo de login. Quando eu mato o processo, o login continua no prompt e é bem sucedido .
Isso não parece ser um problema ssh (d), está mais relacionado a update-motd e paisagem. Desinstalei o pacote update-motd , mas parece que o diretório /etc/update-motd persiste e os scripts ainda são executados - fazendo com que o processo seja interrompido.
Depurando ainda mais:
Acontece que o diretório /etc/update-motd.d/ realmente não pertence ao pacote update-motd , parece ser acionado pela autenticação pam através do sshd.
Parece que eu acertei!
Desativado pam_motd nos seguintes arquivos:
Mais uma:
apt-get purge landscape-client landscape-common
Estes parecem ajudar até certo ponto. No entanto, apenas remove o script incorreto em /etc/update-motd.d/ e nem exclui todos os scripts nesse diretório nem elimina pam_motd .
Em geral, não encontrei nenhuma maneira de desabilitar pam_motd completamente, porque parece que, o que quer que isso faça - isso retarda o processo de login até certo ponto. Não bloqueia como o script em landscape-common , mas é mais lento.
Relatório de erros sobre este problema:
Soluções alternativas de lá:
You are right that the ability to log in is more important than presenting a motd. If this behavior is a problem for you, there are several ways that you can disable it:
- comment out the 'pam_motd' line in
/etc/pam.d/sshdif you don't want to display a motd.- delete the contents of the
/etc/update-motd.ddirectory.- chmod -x the scripts in
/etc/update-motd.dthat you don't want to run.
Encontrei a solução finalmente:
sudo apt-get remove landscape-client landscape-common session optional pam_motd.so e /etc/pam.d/login
Agora, o login é INSTANTÂNEO!
De sua descrição, soa mais como um problema de rede. Para diagnosticar:
Se você puder conectar OK ao Windows e ao PuTTY, provavelmente não será um problema do lado do servidor.
Eu acho que quando você faz o 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 putty funciona, mas Linux, Ubuntu, neste caso, não, geralmente é manter vivo. Problemas de rede ou servidor afetariam o sistema operacional 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ê tiver root access e desejar ativá-lo automaticamente para todos os usuários, edite /etc/ssh/ssh_config , adicione
KeepAlive yes
ServerAliveInterval 120
Se você não tiver acesso root ou ativá-lo para um único usuário, edite ~/.ssh/config e adicione as mesmas duas linhas.
Se PermitEmptyPassword e UsePAM estiverem ativados, o servidor OpenSSH sempre tentará autenticação com uma senha nula, o que é um sinal de que nenhuma autenticação é necessária para a conta em questão. Ele faz isso assim que o processo de autenticação começa, em ambos os protocolos, e não em resposta a qualquer solicitação de autenticação "real"
do cliente. O OpenSSH permitirá somente tal acesso se o sshd_config
flag PermitEmptyPassword está definido; infelizmente, a maneira como o código é
escrito, ele executa o teste de senha em qualquer caso, e assim mostra até
PAM como uma falha.
Então: desative PermitEmptyPassword ou UsePAM , mas lembre-se: sem o PAM, você não conseguirá fazer o login sem uma chave.
Referência: link
Verifique os registros do sistema em / var / log, você pode encontrar uma mensagem com o erro / tempo limite relacionado.
Se você também tiver tempo, espere antes
Edite o /etc/sshd_config
e defina (ou adicione)
UseDNS no
ou adicione seu ip em /etc/hosts se for um local estático
Você pode querer tentar monitorar os processos em execução enquanto faz o login no servidor a partir de uma conexão já com sessão iniciada (ou um console diferente). Há uma chance de identificar quais processos são os mais ativos ou que usam mais CPU naquele momento.
Abaixo está um método possível:
top para ver o que acontece. Por favor, note que se o atraso não for causado por algum cálculo intensivo da CPU, você não encontrará nada fora do lugar. Neste caso, o problema pode estar ligado a E / S (esperando por alguma leitura / gravação de disco ou resposta de rede).
Tags performance ssh server login