Como verificar o log sshd?

126

Eu tenho o Ubuntu 9.10 instalado sshde posso conectar-me com sucesso usando login e senha. Eu configurei um RSAlogin de chave e agora "Servidor recusou nossa chave" conforme o esperado. Ok, agora quero verificar o sshdlog para descobrir um problema. Eu examinei /etc/ssh/sshd_confige tem

SyslogFacility AUTH
LogLevel INFO

Está bem. Estou olhando /var/log/auth.loge ... está vazio O_O. Mudar Loglevelpara VERBOSEnada ajuda - auth.logainda está vazio. Alguma dica de como posso verificar o sshdlog?

ssh

— grigoryvp
fonte

7

Você verificou a configuração do seu syslog? Não executo o Ubuntu, mas ele pode redirecionar o recurso AUTH para um arquivo de log diferente. Talvez / var / log / messages?

— Prof. Moriarty

Como verificar uma configuração de syslog? Infelizmente, eu não sou muito bom a linux :(. cat /var/log/messages | grep sshMostra nada :(.

— grigoryvp

Você está certo. /etc/syslog.confredireciona AUTH para /var/logauth.log. Por favor, escreva sua resposta para que eu possa aceitá-lo :)

— grigoryvp

3

Nos meus servidores, o sshd registra em / var / log / secure. Isso é configurado no /etc/rsyslog.conf, na linha começando "authpriv *."

— Isaac Betesh

1

authpriv ?? Como diabos deveríamos saber que tinha algo a ver com sshd? :-)

— Spencer Williams

7

Se ninguém mais estiver usando o sistema no momento, você poderá fazer o que eu fiz nesses casos:

interromper o serviço sshd (pelo menos eu consegui fazer isso enquanto estava conectado via ssh)
inicie o sshd manualmente e adicione algumas opções -d para obter uma saída de depuração mais detalhada. A menos que você tenha algo estranho, deve usar as mesmas chaves e configurar quando iniciado corretamente

— Peto
fonte

143

Parar o SSHD em um servidor remoto é uma péssima idéia. Isso pode resolver o problema em algumas (ou na maioria) configurações na maioria das vezes, mas se QUALQUER COISA der errado - sua conexão, energia nas duas extremidades, esquecimento, etc. - você estará bloqueado imediatamente. O que é uma má notícia.

— Sudown

1

Bem, note que a única maneira de iniciar o serviço após a interrupção manual seria ter outro tipo de acesso, como outra conexão remota não SSH, ou você está sentado na frente dele.

— Spencer Williams

26

Como isso responde à pergunta? Eu cheguei aqui de uma pesquisa na Web esperando aprender como verificar os arquivos de log SSHD, não o que funcionou para você por algum problema ... Porra, desejo que os leitores da rede Stack Exchange realmente leiam e respondam à pergunta em questão, e não a pergunta que quer que seja ....

4

Você pode iniciar outro sshd em outra porta. Conecte-se a esse. Em seguida, pare o sshd principal e inicie um novo na porta 22. Se algo falhar, reinicie a caixa usando seu DRAC ou gerenciamento de nuvem. Você deve ter o sshd iniciando na inicialização, certo? Não se preocupe.

— de Bruno Bronosky

1

@JoelESalas A comunidade não decide quais respostas são aceitas.

— kasperd

155

Criando uma resposta com base nos comentários acima, credite para @Prof. Moriarty e @Eye of Hell

As falhas de autenticação SSH são registradas aqui /var/log/auth.log

O seguinte deve fornecer apenas linhas de log relacionadas ao ssh

grep 'sshd' /var/log/auth.log

Para garantir a segurança, obtenha as últimas centenas de linhas e pesquise (porque, se o arquivo de log for muito grande, o grep em todo o arquivo consumiria mais recursos do sistema, sem mencionar que levará mais tempo para ser executado)

tail -500 /var/log/auth.log | grep 'sshd'

— RAM
fonte

8

Essa resposta. Outra resposta com a seta verde é falsa. Mude a seta.

— meshfields

5

Por que não usar tail -f ...para monitorar em tempo real? Isso seria um problema com arquivos de log maiores?

— Ing.am

6

less +F ...vai 'cauda' em tempo real, e é muito mais poderoso do que a cauda

— northben

5

E lnavé ainda melhor que menos / tail #

— Wayne Werner

7

Ps: se o seu servidor for um Red Hat (como CentOS), o caminho do log de registros sshd / login é / var / log / secure (verifique na pasta / var / log os arquivos de log de datas específicas também). Veja esta resposta: serverfault.com/questions/465833/…

— Brian Hellekin 5/18

15

Se você puder tentar a conexão com falha novamente facilmente, uma maneira fácil é iniciar um servidor SSH em uma porta livre, como 2222:

/usr/sbin/sshd -d -p 2222

e tente novamente a conexão com:

ssh -p 2222 user@host

Ao usar a porta diferente -p 2222, não precisamos parar o servidor SSH principal, o que poderia nos bloquear.

Consulte também: https://unix.stackexchange.com/a/55481/32558

— Ciro Santilli adicionou uma nova foto
fonte

1

Uma das melhores opções, especialmente se você tiver acesso SSH a um servidor. A depuração da conexão interrompendo o servidor ssh fará com que você saia da sessão. Basta iniciar um novo daemon ssh em uma porta diferente e testar o login usando essa porta.

— Attila Antal

1

Se você deseja ver todas as mensagens de log sobre o sshd, execute o seguinte:

grep -rsh sshd /var/log |sort

— convidado
fonte

2

Os logs começarão com entradas como as Mar 14 19:52:04que excluem o ano e não são facilmente classificadas (embora você possa ter sorte ao sort --month-sortsupor que não ultrapassa um limite entre os anos). Os arquivos de log já estão classificados, portanto, você só precisa verificá-los na ordem certa. Além disso, a grep -rchamada recursiva será muito lenta em sistemas com logs grandes. Não há motivo para verificar adicionalmente coisas como seus logs HTTPD.

— Adam Katz

1

Você pode tail -f /var/log/auth.log

— Aditya Mittal
fonte

1

Bem-vindo ao ServerFault. Você leu a pergunta? Ele não está recebendo dados nesse arquivo. tailinútil se não tiver nenhum dado.

— pintainhos

@chicks Isso é engraçado. Resposta com a maioria dos votos é quase o mesmo como esta ..

— QBack