Minha senha está comprometida porque esqueci de pressionar Enter após o nome de usuário ssh?


142

Eu apenas tentei entrar no servidor do Fedora (versão 13 Goddard) usando SSH (PuTTY, Windows). Por alguma razão, Enterdepois de digitar meu nome de usuário, não digitei e digitei minha senha e pressione Enter novamente. Eu só percebi meu erro quando o servidor me cumprimentou com um feliz

myusername MYPASSWORD @ server.example.com senha:

Interrompi a conexão nesse momento e alterei minha senha nessa máquina (por meio de uma conexão SSH separada).

... agora minha pergunta é: Esse login com falha é armazenado em texto sem formatação em qualquer arquivo de log? Em outras palavras, acabei de forçar minha senha (agora desatualizada) diante dos olhos do administrador remoto na próxima vez que ele verificar seus logs?

Atualizar

Obrigado por todos os comentários sobre a pergunta implícita "o que fazer para evitar isso no futuro". Para conexões rápidas e únicas, usarei esse recurso PuTTY agora:

insira a descrição da imagem aqui

para substituir a opção "onde estava novamente"

insira a descrição da imagem aqui

Também começarei a usar as teclas ssh com mais frequência, conforme explicado nos documentos do PuTTY .


4
Esta é realmente uma boa pergunta. Acho que todos nós digitamos acidentalmente UsernamePassword em algum tipo de serviço em algum momento. É muito fácil de fazer.
user606723

2
Mais um bom motivo para alterar a senha com regularidade razoável.
Jonas19:

25
Você pode evitar isso dizendo ao seu cliente ssh para conectar-se a [email protected] Em seguida, você será solicitado apenas a senha, impossibilitando um acidente como esse. Melhor ainda, porém, seria usar apenas chaves públicas / privadas.
19411 Kevin

1
@ Iceman, obrigado por essa dica - desde que eu sabia que o PuTTY oculta o nome de usuário Connection/Data/Login details/Auto-login username, nunca me ocorreu que o campo "Nome do host (ou endereço IP)" também pudesse aceitar o nome de usuário @ hostname como um cliente ssh da linha de comando adequado.
Jonas Heidelberg

4
Use autenticação baseada em chave.
Zoredache

Respostas:


148

Em resumo: sim.

# ssh 192.168.1.1 -l "myuser mypassword"
^C
# egrep "mypassword" /var/log/auth.log
Oct 19 14:33:58 host sshd[19787]: Invalid user myuser mypassword from 192.168.111.78
Oct 19 14:33:58 host sshd[19787]: Failed none for invalid user myuser mypassword from 192.168.111.78 port 53030 ssh2

21

Se bem me lembro, é realmente registrado no log se o nível de log estiver definido como DEBUG ou TRACE.

EDIT: Está confirmado, tentei entrar no meu servidor e encontrei isso nos meus logs.

Oct 19 14:34:24 sd-xxxx sshd[26563]: pam_unix(sshd:auth): authentication failure; logname=     uid=0 euid=0 tty=ssh ruser= rhost=xxx-xxx-xxx-xxx.rev.numericable.fr 
Oct 19 14:34:26 sd-xxxx sshd[26563]: Failed password for invalid user toto from xxx.xxx.xxx.xxx port 56685 ssh2

Nota: IPs estão ocultos


51
Seus IPs não estão ocultos, eles são apenas postados como algarismos romanos.
Bart Silverstrim

2
, ou palavrões.
10269

8
ou é a meca dos adolescentes na internet - o IP da pornografia.
deanWombourne

10

Ou para segurança e conveniência adicionais, considere realmente configurar as chaves SSH ...

# ssh-keyget -t rsa
(aceite todos os padrões)

e você recebe ...

~ / .ssh / id_rsa
~ / .ssh / id_rsa.pub

Nota: você pode renomear seus arquivos-chave se adicionar ~ / .ssh / config com algo como o seguinte conteúdo:

# cat ~ / .ssh / config
Hospedeiro *
IdentityFile ~ / .ssh / ddopson_employer_id_rsa

Classifique o conteúdo da sua chave pública (será uma única linha):

# cat ~ / .ssh / id_dsa.pub
ssh-rsa AAAAB3NzaC1kc3MAAACBAOOVBqYHAMQ8J ... BbCGGaeBpcqlALYvA == ddopson @ hostname

Agora faça logon na caixa de destino e cole essa linha em ~ / .ssh / allowed_keys.

Nota lateral: a linha pubkey termina em uma sequência legível por humanos, como "ddopson @ hostname". Você pode alterar isso para ser mais descritivo da chave que está usando (por exemplo, se você tiver muitas chaves). Essa cadeia NÃO é usada como parte da autenticação e é apenas para descrever a chave para outros seres humanos.

É isso aí. Agora, quando você fizer o ssh no host, nem será solicitada uma senha.

Se você estiver preocupado em armazenar sua chave privada (id_rsa), poderá adicionar uma senha à própria chave (consulte ssh-keygen), protegendo-a do uso por qualquer pessoa que tenha acesso aos seus arquivos. Você pode usar o ssh-agent para descriptografar a chave e armazená-la com segurança na memória, para que possa ser usada para várias conexões SSH.


Eu provavelmente deveria ter adicionado uma windows-clientstag à minha pergunta. Este tutorial explica como tornar as chaves ssh utilizáveis ​​com o PuTTY.
Jonas Heidelberg

você pode fazer exatamente a mesma coisa com o PuTTY. Você pode adicionar chaves ao PuTTY ou usar o PuTTYgen para gerar as chaves. Mesma história, comandos diferentes. (Eu acho que está na guia de autenticação dos parâmetros de conexão).
quer

0

A senha foi criptografada quando transmitida. Sim, é possível que sua senha tenha sido comprometida porque foi impressa no log no servidor de destino. No entanto, eu também diria que toda vez que você digitar sua senha no seu computador, ela poderá ser comprometida, pois pode haver software spyware no seu computador ou um keylogger conectado ao seu computador.

Se você é o único administrador desse sistema e acredita que esse sistema não foi comprometido, você pode assumir com relativa segurança que sua senha não foi comprometida, assim como você normalmente supõe que não há spyware no seu computador, porque você não possui testemunhou algo suspeito. Você pode editar o log nesse servidor e remover a referência à sua senha.

Esse incidente é uma das razões pelas quais é melhor usar chaves SSH em vez de senhas. Então, mesmo que alguém receba a senha que você digita no seu computador para descriptografar a chave privada no seu computador, eles ainda não poderão acessar o servidor remoto; eles também precisam do próprio arquivo de chave privada. Segurança é tudo sobre camadas. Nada é perfeito, mas se você adicionar camadas suficientes, é difícil o suficiente para o atacante seguir em frente ou capturá-las porque leva mais tempo.

Eu não faria isso acima se sua senha proteger informações muito sensíveis ou recursos críticos. Depende da sensibilidade da sua senha.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.