Por que devo usar a Autenticação de Chave Pública para SSH?

Question

Estou executando um servidor SSH e ainda estou usando a autenticação de senha simples. Em todos os lugares que leio sobre segurança, aconselho usar a Autenticação de Chave Pública. Mas eu não entendo as vantagens. Usá-los é, aos meus olhos, inseguro ou muito útil.

É claro que, se alguém tentar forçar o login no meu servidor SSH, Public-Key será muito mais strong que qualquer senha. Mas além disso, é totalmente inseguro.

Os consultores argumentam que você não precisa se lembrar de uma senha. Quão inseguro é isso? Então, se alguém invadir meu computador, ele não apenas pega meu computador, mas também meu servidor? Se eu estou usando o SSH de vários clientes diferentes, eu tenho que armazenar as chaves públicas uma a cada uma delas, o que multiplica a possibilidade de elas caírem nas mãos falsas. Eu poderia salvá-los em um pendrive que carrego comigo, mas ele pode ser perdido e o localizador tem acesso ao meu servidor.

Possivelmente estou mais bem servido com autenticação de dois fatores.

Existe algum argumento que estou perdendo? Qual é o melhor caminho para mim?

    

Answer 1

if someone hacks into my computer, he doesn't just get my computer, but my server too?

Isso é potencialmente verdadeiro de qualquer maneira com os keyloggers: assim que você faz o login no seu servidor a partir do computador comprometido, eles recebem a senha.

Mas há 3 vantagens para as chaves:

1) Autenticação em cache. Digite sua senha uma vez, execute vários comandos ssh. Isso é muito útil se você estiver usando algo que usa ssh como transporte, como scp, rsync ou git.

2) Autenticação escalonável. Digite sua frase secreta uma vez, faça login em várias máquinas . Quanto mais máquinas você tiver, mais útil isso é. Se você tem 100 máquinas, o que você faz? Você não pode usar a mesma senha (a menos que seja um farm clone), e você não consegue se lembrar disso. Então você teria que usar um gerenciador de senhas e voltar ao ponto de compromisso único. Efetivamente, a frase secreta de chave é seu gerenciador de senhas.

2b) Ele é dimensionado de outra maneira se você tiver vários administradores usando os mesmos sistemas, porque você pode revogar as chaves do usuário A sem precisar informar que a senha foi alterada por B, C, D, E, F ... .

(Isso também pode ser feito com contas individuais e sudo, mas você precisa provisionar essas contas de alguma forma)

3) Automação e delegação parcial. Você pode configurar o SSH para executar um comando específico quando uma tecla conecta . Isso permite que um processo automatizado no sistema A faça algo no sistema B sem ter confiança total sem senha entre os dois.

(É um substituto para o rlogin / rsh, que era hilário e inseguro)

Editar: outra vantagem para chaves públicas em vez de senhas é o cenário comum em que o servidor é comprometido por meio de uma vulnerabilidade. Nesse caso, o login com uma senha compromete a senha imediatamente. Entrar com uma chave não! Eu diria que isso é mais comum do que a área de trabalho de origem do administrador que está sendo comprometida.

    

Answer 2

Se você estiver usando boas senhas, isso pode ser seguro o suficiente. Eu costumo limitar o número de servidores publicamente acessíveis ao mínimo e permitir SSH de IP específico (s) sempre que possível.

Além disso, você pode proteger suas chaves por frase secreta (senha). Portanto, essa frase secreta deve ser inserida sempre que você precisar fazer o login no (s) seu (s) servidor (es). Ninguém pode usar sua chave a menos que a frase certa seja fornecida.

Existem postagens semelhantes:

1. Publique no serverfault .
2. Publique de segurança stackexchange .
3. Publique no superusuário .

Answer 3

Uma maneira em que a autorização de chave pública é mais segura é quando o invasor consegue ser man-in-the-middle (MitM) entre seu computador cliente e o servidor, e você não percebe a alteração da chave do host (possivelmente porque você não tinha a chave antiga, por exemplo, porque esta é a primeira vez que usa este computador cliente específico).

(O mesmo se aplica quando o invasor consegue assumir o controle do servidor e há outros servidores em que as mesmas credenciais funcionam.)

Com a autenticação baseada em senha padrão, você está enviando sua senha (dentro da conexão criptografada) em texto simples, o servidor genuíno normalmente a confundirá e comparará o resultado a um hash armazenado em seu banco de dados de senhas. Um invasor MitM poderia, em vez disso, pegar essa senha, abrir uma conexão com o servidor real e fazer o login lá ... e encaminhar o conteúdo para você (para que você não perceba nada) ou apenas fazer o seu próprio mal no seu servidor .

Com a autenticação de chave pública, o cliente está basicamente assinando alguns dados conhecidos pelo servidor e pelo cliente para provar que possui a chave privada e envia a assinatura para o servidor. Esses dados assinados incluem um identificador de sessão, que depende de números aleatórios escolhidos pelo cliente e pelo servidor e, portanto, é diferente para cada sessão. Se o MitM abrir sua própria conexão SSH com o servidor real, ele terá um ID de sessão diferente e, portanto, a assinatura fornecida pelo cliente não funcionará lá.

É claro que, como outras respostas já foram contadas, você precisa manter sua chave privada protegida, por exemplo, criptografado com uma senha, ou possível em um dispositivo separado, que cria apenas assinaturas após inserir um PIN.

    

Answer 4

O OpenSSH pode manter sua própria autoridade de certificação para gerenciar chaves de host e cliente SSH e pode usar listas de revogação nelas. Isso pode aumentar a segurança fornecida pela autenticação baseada em chave.

    

Answer 5

Você está certo sobre a reivindicação "você não precisa de uma senha". Isso é realmente inseguro no lado do cliente.

O que torna permitido que chaves públicas somente façam login muito mais seguro é o fato de que não há como fazer um acesso bruto ao seu servidor. Tudo o que um atacante pode conseguir é colocar alguma carga no seu servidor - você pode empregar o fail2ban para manter isso sob controle.

Por segurança no lado do cliente, você deve proteger a chave privada com uma boa frase secreta. Claro que agora conectar-se ao servidor é mais trabalhoso do que com uma senha. Para superar isso, você pode usar o ssh agent para armazenar a chave privada na memória, caso pretenda se conectar ao servidor várias vezes seguidas. É uma boa prática limitar o tempo por quanto tempo uma chave deve ser mantida na memória.

    

Answer 6

Possibly I am better served with Two-Factor Authentication.

Uma possibilidade para 2FA para SSH (e uma que requer relativamente pouca configuração / complexidade) é de fato usar uma chave pública e senha.

Acredito que algo nos moldes de AuthenticationMethods publickey,keyboard-interactive possa ser adicionado a /etc/ssh/sshd_config para que isso funcione.

Mais geralmente, o problema é mais que as senhas (sozinhas) não são um ótimo método de autenticação, porque elas são frequentemente de qualidade duvidosa. Um 'argumento' muito simples para chaves versus senhas é que uma chave geralmente terá pelo menos 2048 bits e, frequentemente, mais (para chaves EC, essa seria a força efetiva, em vez do tamanho real). Esses bits também são gerados por um mecanismo criptologicamente seguro (ou apropriado).

Uma senha é geralmente menor que 2048 bits e geralmente não é derivada de uma fonte criptograficamente segura.

Você também pode proteger suas chaves com uma senha, para se proteger contra problemas relacionados a perdê-las (embora alguém possa tentar forçar essa senha).

Então, basicamente, as diferenças podem ser bastante transparentes entre chaves e senhas, e o uso de chaves oferece uma senha melhor do que um ser humano poderia lidar. Isso não quer dizer que eles são uma panacéia, mas, em média, eles fornecem mais segurança do que senhas.