Por que a autenticação de senha SSH é um risco à segurança?

68

A maioria dos guias para configuração do OpenSSH recomenda desativar a autenticação de senha em favor da autenticação baseada em chave. Mas, na minha opinião, a autenticação por senha tem uma vantagem significativa: a capacidade de conectar-se absolutamente de qualquer lugar sem uma chave. Se usado sempre com uma senha forte, isso não deve ser um risco de segurança. Ou deveria?

Septagrama
fonte
2
As senhas são autenticação de um fator que pode ser detectada, adivinhada e reproduzida. As chaves são (possivelmente) de dois fatores. Ser capaz de fazer login de qualquer lugar com apenas um fator é inaceitável em alguns sistemas.
Alex Holst

Respostas:

25

Existem prós e contras para autenticação baseada em chave ou pw.

Em alguns casos, por exemplo, a autenticação baseada em chave é menos segura que a autenticação por senha. Em outros casos, é baseado em pw e menos seguro. Em alguns casos, um é mais conveniente, em outros, menos.

Tudo se resume a isso: Quando você faz a autenticação baseada em chave, deve proteger sua chave com uma senha. A menos que você tenha o ssh-agent em execução (o ssh-agent o libera de inserir sua senha sempre), você não ganhou nada em termos de conveniência. A segurança é discutível: o vetor de ataque agora passou do servidor para VOCÊ, sua conta ou sua máquina pessoal, (...) - esses podem ou não ser mais fáceis de quebrar.

Pense fora da caixa ao decidir isso. Se você ganha ou perde em termos de segurança, depende do restante do seu ambiente e de outras medidas.

edit: Ah, acabei de ver que você está falando de um servidor doméstico. Eu estava na mesma situação, "senha" ou "pendrive com chave" sempre comigo? Eu optei pelo primeiro, mas mudei a porta de escuta do SSH para algo diferente de 22. Isso impede que todos aqueles jovens com scripts coxos brutais forcem intervalos de rede inteiros.

romano
fonte
Alterar a porta SSH de 22 pode não ser uma boa ideia em muitos casos. adayinthelifeof.nl/2012/03/12/…
Tymek
75

O uso de chaves ssh tem um recurso exclusivo em comparação ao login com senha: você pode especificar os comandos permitidos. Isso pode ser feito modificando o ~/.ssh/authorized_keysarquivo no servidor.

Por exemplo,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

permitiria apenas o comando `/usr/local/bin/your_backup_script.sh" com essa chave específica.

Você também pode especificar os hosts permitidos para a chave:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Ou combine os dois:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Com as chaves, você também pode conceder acesso temporário a algum usuário (por exemplo, um consultor) a um servidor sem revelar a senha para essa conta específica. Depois que o consultor termina seu trabalho, a chave temporária pode ser removida.

Janne Pikkarainen
fonte
Dica muito, muito útil.
Sachin Divekar
3
Para além disso utilizando as teclas é como ter uma senha longa de caracteres 2000 (bem tecnicamente a sua ainda mais força) em comparação com o que você pode digitar manualmente em um terminal: D
Abhishek Dujari
3
Faz duas dicas muito úteis sobre a autenticação SSH, mas realmente não responder à pergunta por mim ...
MikeMurko
Se você deseja forçar um usuário autenticado por senha a executar um comando específico, altere seu shell de login. Além disso, "conceder acesso temporário sem revelar a senha" é uma péssima idéia. Existem centenas de maneiras diferentes de manter o acesso para mais tarde.
b0fh
O último parágrafo, por si só, responde à pergunta: as chaves IMO permitem a revogação granular, enquanto que com as senhas, você precisa informar a todos que a está alterando.
Riking 21/02
48

Você pode obter o melhor dos dois mundos, permitindo apenas a autenticação de senha na sua rede. Adicione o seguinte ao final do seu sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes
MikeyB
fonte
7

Você respondeu parcialmente à sua pergunta - quanto mais lugares o atacante puder se conectar, mais possibilidades ele terá de invadir o servidor por força bruta (considere DDoS).

Compare também o tamanho da sua senha com o tamanho da chave (geralmente milhares de bits).

Martin Vejmelka
fonte
4
96 bits de entropia significa uma senha de 80 caracteres, se estiver escrita em inglês; 15 caracteres, se for um conjunto aleatório do conjunto de caracteres imprimíveis. você tem certeza de que suas senhas ssh são longas / fortes?
MadHatter
3
Se você tiver várias senhas com entropia de 96 bits que não serão vulneráveis ​​a ataques do Dictionary, provavelmente precisará usar algum tipo de software de gerenciamento de senhas, para perder efetivamente o elemento acessível em qualquer lugar do uso de senhas .
Nick Downton #
5
@SachinDivekar que contém 96 bits de entropia apenas se usar senhas aleatórias do conjunto [a-zA-Z], não se forem palavras em inglês.
Jaap Ancianidade
16
@NickDownton - Você pode ter uma senha longa e agradável sem recorrer ao software de keypass. Algo como mywifesnameisangelaandshehasanicebutté invencível para ataques de dicionário, é muito forte e muito simples de lembrar, mas impossível de adivinhar. E vem com o bônus se o brownie apontar, se você precisar fornecer sua senha à sua esposa.
Mark Henderson
7
Desculpe, Mark, mas isso está errado. A senha que você fornece possui 37 caracteres e, portanto, aproximadamente 44 bits de entropia, que é mais fraca que 7 caracteres imprimíveis aleatórios e é eminentemente atacável. Leia o artigo da Wikipedia sobre o trabalho de Claude Shannon para obter detalhes, mas o resultado é que o inglês escrito é altamente previsível - por exemplo, depois de "mywifesname", a palavra "is" é quase garantida. Para senhas fortes envolvendo palavras, quatro palavras aleatórias reunidas em um dicionário oferecem 10 ** 23 possibilidades, ou seja, cerca de 77 bits de entropia; ainda não é ótimo, mas não é ruim.
MadHatter
7

Quando você faz login com uma senha, transmite sua senha ao servidor. Isso significa que o operador do servidor pode modificar o SSHD para obter acesso à sua senha. Com a autenticação de chave pública, eles não podem obter sua chave privada, pois apenas sua chave pública é acessada no servidor.

Ramon
fonte
2
Isso é especialmente relevante quando você se conecta ao servidor errado devido a um erro de digitação. Por exemplo, em algum momento, .cg era um curinga apontando para uma única máquina com o ssh ativado. Sempre que você iria mistype .cg para .ch, que acabaria por se conectar a essa caixa e vazando sua senha ...
b0fh
@ b0fh de fato. Até onde eu sei, essa é a única vulnerabilidade real introduzida usando senhas com ssh. Se alguém já possui o servidor ao qual está se conectando ou pode falsificar os endereços IP aos quais está se conectando (MITM), você já perdeu.
hobs
6

As teclas ssh evitam ataques do tipo intermediário à sua senha.

Quando você tenta fazer login com uma chave, o servidor cria um desafio com base na sua chave pública e a envia ao seu cliente. que o descriptografará e criará uma resposta apropriada para enviar.

Sua chave privada nunca é enviada ao servidor e qualquer pessoa que esteja escutando não pode fazer nada, exceto interceptar essa única sessão.

com uma senha, eles teriam suas credenciais.

Minha solução é ter uma chave ssh portátil em formatos adequados em uma partição criptografada em uma chave USB. isso me permite:
facilmente retirar essa chave no caso de ela ser perdida.
restringir quais servidores me permite acessar
e ainda carregá-lo

embora instalar o software de montagem seja um problema (truecrypt)

Tacticus
fonte
11
Isto está errado. Assim que você souber a chave pública do servidor (o que você faz se a adicionou ao cache e não conseguiu o MITM na primeira conexão), você fica imune a ataques do MITM. A autenticação baseada em chave / senha não tem nada a ver com isso. A senha nunca é enviada de forma clara, uma conexão segura na autenticação no nível da máquina (qual é a sua / minha chave pública) é sempre configurada antes da autenticação no nível do usuário (qual é a sua senha / prova para mim que essa chave pública é sua) .
Thomas
3
Thomas, na realidade, muitas pessoas ignoram o aviso sobre uma alteração na impressão digital. A autenticação do Pubkey garante proteção MITM, mesmo que a chave privada do servidor seja comprometida de alguma forma ou se um humano digitar "sim" distraidamente: O invasor deve escolher entre não conseguir ver o tráfego e enviar uma chave pública que não fará login, o que é um ganhar.
Score_Under
5
E para o respondente: você não precisa usar truecrypt, as chaves privadas do openssh vêm com sua própria criptografia opcional baseada em senha.
Score_Under
5

É uma troca, como @MartinVejmelka diz.

O motivo pelo qual você usa autenticação baseada em chave é que a chave está tão acima da força bruta atual ou próxima do futuro que você precisa vir do seu próprio PC ou ter a chave em um pendrive ou similar.

Uma senha tem os seguintes problemas:

  • Se for curto, pode ser brutal forçado
  • Se for longo, é facilmente esquecido
  • Poderia ser surfado no ombro

Uma chave tem ordens de magnitude mais longas e não é exibida em nenhum momento, portanto evita esses três problemas.

Rory Alsop
fonte
mas o uso de um arquivo de chave adiciona a questão da perda do pen drive ou do armazenamento que você estiver usando.
João Portela
11
Nesse ponto, a chave perdida pode ser removida e uma nova chave adicionada. Com senhas (especialmente senhas compartilhadas), isso pode ser uma grande dor e envolve muitos gemidos.
precisa
Uma das minhas senhas (recém-reformados): 08Forging2?seminal*^Rajas-(Posed/|. É gerado aleatoriamente, mas não tenho problemas em lembrar. E boa sorte surfando nos ombros ou forçando-o com força bruta.
finnw
11
@finnw Grampo correto da bateria do cavalo :-) security.stackexchange.com/q/6095/485
Rory Alsop
2

Bons pontos mencionados aqui já.

O que eu considero o maior risco, considerando que você cuidou do básico com uma senha forte, é que muitos computadores possuem keyloggers instalados sem que o usuário perceba. Existem até pessoas criando sites inteiros de utilitários úteis que contêm cavalos de Troia, para que isso possa acontecer com o melhor de nós. Um keylogger, por exemplo, enviaria os detalhes de login por e-mail para um hacker, que poderia acessar facilmente o servidor.

Recentemente, fui avisado pelo Norton sobre o download do instalador do Zombee Mod (não do jar, o instalador) por adicionar um voo ao jar do Minecraft. Analisei os detalhes e o Norton listou muitos utilitários neste site que foram marcados como contendo um trojan. Não sei se isso está correto ou não, mas era bastante específico nos nomes de arquivos. Também é um fato conhecido que os trojans são colocados em (alguns) warez antes de serem distribuídos.

Tedd Hansen
fonte
2

Um benefício potencial do SSH sobre as senhas é que, se você não especificar uma senha de SSH, nunca precisará digitar uma senha novamente ... seu computador é intrinsecamente confiável no servidor porque possui a chave. Dito isto, eu costumo sempre usar uma senha SSH, então eu descarto esse benefício.

Eu encontro a melhor resposta para o motivo pelo qual os guias do usuário recomendam frequentemente o SSH sobre autenticação de senha vem do manual do Ubuntu para SSHOpenSSHKeys. Eu cito,

Se você não acha importante, tente registrar todas as tentativas de login mal-intencionadas que você obter na próxima semana. Meu computador - um PC de mesa perfeitamente comum - teve mais de 4.000 tentativas de adivinhar minha senha e quase 2.500 tentativas de invasão somente na última semana. Quantos milhares de palpites aleatórios você acha que serão necessários antes que um invasor tropece na sua senha?

Essencialmente, se você tiver uma senha sólida de alto comprimento com pontuação, maiúsculas e minúsculas e números ... provavelmente estará bem com a autenticação de senha. Além disso, se você planeja monitorar seus logs e não está fazendo coisas "super seguras" pela rede de qualquer maneira ... ou seja, usando-o para um servidor doméstico. Então, por todos os meios, uma senha funciona bem.

MikeMurko
fonte
1

O método de autenticação por senha é realmente inseguro (imho). Com esse mecanismo, a senha será transmitida ao servidor sshd (como o @ramon já disse). Isso significa que algumas pessoas podem modificar o servidor sshd para recuperar a senha. Com um ataque Man-In-The-Middle, isso é muito fácil de realizar dentro de uma rede local.

Você pode simplesmente corrigir o servidor sshd instalando esse patch ( https://github.com/jtesta/ssh-mitm ). Use arpspoofe iptablespara colocar seu servidor corrigido entre o cliente e o servidor sshd autêntico.

Desabilite a autenticação da senha: abra o arquivo de configuração /etc/ssh/ssh_confige adicione a linha PasswordAuthentication no.

Pioz
fonte
O cliente SSH não verifica o servidor quanto à impressão digital RSA? Depois que você transfere o servidor para este servidor em particular pelo menos uma vez, sua impressão digital é lembrada; portanto, no caso de possíveis ataques MITM, o SSH acenderá um aviso, não é?
Septagram
11
Sim. O aviso aparece, mas porque 99% do tempo é causado pela reinstalação do sistema operacional, configuração alterada ecc, a maioria dos usuários ignora o aviso e continua.
Pioz
@Septagram Muitos provedores de conta shell não têm o hábito de postar a impressão digital da chave do servidor atual para novos assinantes, para a migração de contas de usuário para novos servidores, etc.
Damian Yerrick
-2

Você pode ignorar o com a -o StrictHostKeyChecking=noopção Isso é muito útil ao usar ssh em um script de shell.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost
arganzheng
fonte