Preciso substituir as chaves do OpenSSH em resposta ao Heartbleed?


9

Eu já atualizei meus servidores com os patches.

Preciso regenerar alguma chave privada em relação ao OpenSSH? Eu sei que tenho que regenerar quaisquer certificados SSL.

Edição: eu não palavra isso com precisão suficiente. Sei que a vulnerabilidade está no openssl, mas estava perguntando como isso afeta o openssh e se preciso gerar novamente as chaves do host openssh.


1
Na verdade, esta é provavelmente uma duplicata de serverfault.com/questions/587329/...
faker

Seu primeiro e terceiro parágrafos parecem contraditórios.
um CVn

@faker Não é verdade - essa pergunta não resolve nada sobre SSH ...
voretaq7

Respostas:


5

A vulnerabilidade não afeta, opensshmas afeta openssl.
Qual é uma biblioteca usada por muitos serviços - inclusive openssh.

Neste momento, parece claro que opensshnão é afetado por esta vulnerabilidade, porque o OpenSSH usa o protocolo SSH, não o protocolo TLS vulnerável. É improvável que sua chave privada ssh esteja na memória e seja legível por um processo vulnerável - não impossível, mas improvável.

Claro que você ainda deve atualizar sua opensslversão.
Observe que, se você atualizou, openssltambém precisará reiniciar todos os serviços que o estão usando.
Isso inclui software como servidor VPN, servidor web, servidor de email, balanceador de carga, ...


1
Algo a ter em mente: É possível usar a mesma parte de chave privada para uma Chave Privada SSH e um Certificado SSL. Nesse caso, se a chave de certificado SSL foi usada em um servidor da Web vulnerável, você também precisaria substituir a chave privada SSH afetada. (Para que isso seja explorado, alguém precisará saber que você está fazendo isso ou pensar em experimentá-lo - é uma configuração MUITO incomum em minha experiência, por isso duvido que alguém pense nisso). Tudo o que disse que não há nada de errado com regenerando o seu SSH chave privada (s), se você quiser - um pouco de paranóia não é uma coisa ruim :-)
voretaq7

2

Portanto, parece que o SSH não é afetado:

Geralmente, você é afetado se executar algum servidor em que gerou uma chave SSL em algum momento. Usuários finais típicos não são afetados (diretamente). SSH não é afetado. A distribuição dos pacotes Ubuntu não é afetada (depende de assinaturas GPG).

Fonte: ask ubuntu: Como corrigir o CVE-2014-0160 no OpenSSL?


1

Diferentemente do que outros disseram aqui, Schneier diz que sim.

Basicamente, um invasor pode obter 64K de memória de um servidor. O ataque não deixa rastro e pode ser feito várias vezes para obter 64K de memória aleatória diferente. Isso significa que qualquer coisa na memória - chaves privadas SSL, chaves de usuário, qualquer coisa - é vulnerável. E você deve assumir que tudo está comprometido. Tudo isso.

Não é que o ssh (qualquer tipo) tenha sido afetado diretamente, mas essas chaves ssh podem ser armazenadas na memória e a memória pode ser acessada. Isso vale para praticamente qualquer outra coisa armazenada na memória que é considerada secreta.


Ele parece dar uma visão geral do problema com esta frase. É a primeira vez que ouço que todos toda a sua memória foi exposta. Até agora, meu entendimento é que apenas a memória à qual o processo vulnerável tem acesso é exposta. Veja também: security.stackexchange.com/questions/55076/…
faker

0

O OpenSSH não usa a extensão de pulsação, portanto o OpenSSH não é afetado. Suas chaves devem estar seguras desde que nenhum processo OpenSSL que faça uso de batimentos cardíacos as tenha em sua memória, mas isso geralmente é muito improvável.

Portanto, se você é / precisa ser um pouco paranóico, substitua-os; caso contrário, você pode dormir relativamente bem sem fazer isso.


O SSH não usa o OpenSSL. Grande diferença lá.
Jacob

2
O OpenSSH usa a parte libcrypto do OpenSSL. É por isso que você precisa reiniciar o SSH após atualizar o OpenSSL. É por isso que algumas pessoas estão perguntando se precisam substituir suas chaves SSH. Veja minha resposta acima ... Então, qual é o seu ponto exatamente?
Denis Witt
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.