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

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:

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

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

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

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

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.

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.