Por que a autenticação de chave SSH é melhor que a autenticação por senha?


45

Isso não é tanto uma questão técnica quanto conceitual. Entendo que a criptografia usada em uma chave SSH é muito mais forte que uma senha comum, mas não entendo por que é considerada mais segura.

A maioria dos tutoriais que li sugerem o uso da autenticação por chave SSH em vez da autenticação por senha. Mas meu entendimento é que quem tiver acesso a uma máquina cliente pré-aprovada poderá conectar-se ao servidor, o que significa que o nível de segurança fornecido pela chave SSH é tão forte quanto o nível de segurança do sistema físico. máquina cliente.

Por exemplo, se eu configurar uma chave SSH no meu telefone para conectar à minha máquina doméstica, caso eu perca o telefone e alguém consiga desbloqueá-la, eles poderão se conectar à minha máquina doméstica. Sei que posso remover a chave do telefone da minha máquina doméstica, mas estou vulnerável até perceber que o dispositivo cliente foi perdido / violado.

Eu entendi mal alguma coisa ou essas são preocupações válidas?


10
Faça as duas coisas - uma chave que requer uma senha. Dessa forma, você precisa que duas coisas sejam identificadas, não apenas uma. Você também pode invalidar chaves perdidas com bastante facilidade e ter várias chaves autorizadas para ter mais controle sobre isso, etc.
Phoshi

2
Provavelmente, isso deve ser movido para a segurança.

10
@DKGasser: Não, não deveria. É uma pergunta perfeitamente válida aqui. Só porque algo pode ser movido para outro site SE não significa que deveria .
Wuffers

4
@DKGasser: Poderia ir para esse site, é uma pergunta perfeitamente válida lá. Mas também é uma pergunta válida aqui, portanto não há razão para migrá-la. Se essa questão fosse excluída do tópico aqui, sim, ela poderia ser migrada para lá. Mas é totalmente sobre tópicos neste site e, portanto, não deve ser migrado.
Wuffers

3
E não se esqueça, a chave SSH nunca passa pela rede. O servidor remoto NUNCA obtém a chave, ao contrário de uma senha, que não é apenas enviada pela rede, mas enviada ao servidor remoto. Pense na próxima vez que não tiver certeza de qual senha usar e tente algumas ... que talvez sejam usadas em outras contas! Quais senhas você enviou para esse servidor ???
jm 18/07/2017

Respostas:


40

Se o seu serviço SSH permitir autenticação baseada em senha, o servidor SSH conectado à Internet será martelado dia e noite por redes de bots tentando adivinhar nomes de usuário e senhas. A rede bot não precisa de informações, pode apenas tentar nomes e senhas populares. Há muitas pessoas chamadas john com uma senha qwerty123. Além de qualquer outra coisa, isso obstrui seus logs.

Se o seu serviço SSH permitir apenas a autenticação de chave pública, o invasor precisará de uma cópia de uma chave privada correspondente a uma chave pública armazenada no servidor. Eles não podem apenas fazer ataques aleatórios, eles precisam ter conhecimento prévio de seus usuários e devem poder roubar uma chave privada do PC de um usuário autorizado do seu servidor SSH.

O fato de que as chaves privadas geralmente são protegidas por uma frase longa é de importância secundária.

Atualizar:

Como os comentários apontam, e como eu experimentei, mover o serviço SSH da porta 22 para uma porta numerada alta faz uma diferença drástica no número de tentativas de login não autorizadas que aparecem nos seus logs. Vale a pena fazer isso, mas eu a considero uma forma de segurança pela obscuridade (uma falsa sensação de segurança) - mais cedo ou mais tarde, as redes de bots implementam a varredura de porta furtiva lenta ou você será deliberadamente direcionado. Melhor estar preparado.

Eu sempre uso uma frase longa para proteger minha chave privada, acho que isso é de particular importância em dispositivos móveis que podem ser perdidos ou roubados com mais facilidade.

Além disso, http://xkcd.com/538/

Segurança


7
+1, exceto que a autenticação de chave pública não fará nada para seus logs ficarem entupidos com os bots tentando se conectar. Para parar isso, execute o servidor SSH em uma porta alta (ou seja, 9876 em vez de 22). Então, se eles querem bater em você têm que PortScan você primeiro, e robôs geralmente não perca muito tempo ... há uma abundância de servidores SSH em 22.
Ex Umbris

3
Você não está brincando com o tamanho do log - meu / var / log / secure passou de megabytes de tentativas de login para kilobytes (com apenas meus registros de login).
John C

2
+1 Interessante, eu corro com autenticação baseada em senha por .. há 10 anos .. lol .. Concedido, minhas portas ssh publicamente expostas nunca são a porta 22. Acho que as redes de bots vão me varrer e tentar invadir todos os porta eles podem ?? Boa informação, obrigado.
James T Snell

2
@ExUmbris, em vez de alterar a porta, considere usar o fwknop: Autorização de Pacote Único e Batida na Porta . O benefício aqui deve ser óbvio: quando você não permite que ninguém veja que a porta está aberta em qualquer lugar, a menos que tenham acesso à porta ao bater com o SPA, eles não podem nem tentar encontrá-la com nmap e explorá-lo. Isso é muito melhor do que simples segurança através da obscuridade.
Aculich 29/10/12

@aculich Alterar a porta não é "segurança através da obscuridade". Tudo o que estou fazendo é impedir que os logs sejam preenchidos com avisos. No entanto, você tem um ponto válido sobre como melhorar a segurança com o SPA.
Ex Umbris

8

A lógica é que existem muito mais combinações de chaves SSH do que senhas, portanto, é muito mais difícil adivinhar. O uso de chaves SSH também permite desativar a autenticação de senha, o que significa que a maioria dos ataques automatizados que circulam na Internet será inútil.

No que diz respeito à segurança física, não há diferença entre salvar uma senha e ter uma chave SSH não criptografada no dispositivo, se ela for perdida ou roubada. A única vantagem que você tem é que ninguém tem sua senha e, teoricamente, você pode garantir que todos os dispositivos possuam certificados SSH diferentes, para que você possa desativar a senha do seu telefone.

Eu acredito que também é possível proteger com senha as chaves SSH.


Vale ressaltar, no entanto, que tentativas de força bruta de senha contra sshd podem ser detectadas e protegidas (por exemplo, por fail2ban), enquanto alguém que roubou sua chave privada pode tentar senhas nela tão rápido quanto o computador (ou cluster) permitir. eles. Isso ainda não é um grande ataque , mas eles aumentaram drasticamente suas chances em comparação com uma política fail2ban razoável.
Xiong Chiamiov


1

As senhas também podem ser comprometidas pelo monitoramento do teclado "por cima do ombro". Além disso, o uso de senhas semelhantes em muitos lugares é uma fraqueza, especialmente se a senha é usada algumas vezes em um computador menos seguro com potenciais keyloggers.

Você está certo de que uma chave não criptografada pode ser lida no disco rígido se o computador for roubado - então criptografe-o com uma senha.

Se o seu computador estiver comprometido por malware, você estará cheio de qualquer maneira .. - alguém pode obter a chave criptografada e registrar sua senha com senha.


1
Nota: mas você não pode criptografar sua chave com uma senha se ela for usada programaticamente (por exemplo, em um script).
TheStoryCoder
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.