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

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?

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.

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.

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

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).

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.

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)

É 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.

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.

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.

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.

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