Quão ruim é ter vários dispositivos com as mesmas chaves de servidor SSH?

Estou trabalhando em um dispositivo incorporado que roda o FreeBSD e o SSH.

Como você sabe, o sshd gosta de gerar aleatoriamente um conjunto de chaves do servidor quando é inicializado. O problema é que enviaremos o produto com um sistema de arquivos de cartão SD somente leitura (não negociável).

Minhas duas opções como eu as vejo são:

• Envie as mesmas chaves de servidor sshd em todos os dispositivos
• Monte um sistema de arquivos de memória e gere as chaves do servidor em cada inicialização (lento ...)

É um grande problema de segurança enviar as mesmas chaves do servidor em todos os dispositivos? Esses itens não estarão diretamente na internet. Ocasionalmente, haverá vários dispositivos pertencentes à mesma pessoa e na mesma rede.

Na maioria das vezes, o dispositivo não será conectado à Internet.

O login com SSH não faz parte da operação normal. É principalmente para a conveniência dos programadores e técnicos. Os clientes não farão login no dispositivo com SSH.

Quais são as ramificações do uso das mesmas chaves de servidor em vários dispositivos de hardware?

PS alguém poderia, por favor, criar uma etiqueta de Internet das Coisas?

EDIT : Estou falando sobre a instalação das mesmas chaves privadas de host em todos os servidores (dispositivos). No que diz respeito às chaves públicas / privadas do usuário, atualmente não há planos de usar o login baseado em chave - seria o login com senha. Novamente, a mesma senha em todos os servidores (dispositivos).

Eu sei que isso provavelmente é uma má ideia. Eu gostaria de saber por que exatamente é uma má ideia, para que eu possa entender as vantagens e desvantagens.

Em vez de armazenar dados específicos de host, como chaves de host ssh no cartão SD ou outra mídia somente leitura, você pode armazená-lo na NVRAM, que é para isso em um sistema incorporado. Você precisará criar scripts personalizados para armazenar e recuperar as chaves no momento da inicialização, mas os scripts serão exatamente iguais para todos os dispositivos.

O impacto do envio do mesmo par de chaves com todos os seus dispositivos está diretamente relacionado à segurança dos clientes que se conectam a eles, pois significa que não há como (de um cliente SSH) identificar exclusivamente o dispositivo ao qual ele está se conectando. Se seu par de chaves vazar, ele poderá ser usado para ataques MITM.

Por outro lado, a regeneração das chaves em cada inicialização também acionará um alerta nos clientes.

Para referência, de man ssh(1):

sshmantém e verifica automaticamente um banco de dados contendo a identificação de todos os hosts com os quais já foi usado. As chaves do host são armazenadas no ~/.ssh/known_hostsdiretório inicial do usuário. Além disso, o arquivo /etc/ssh/ssh_known_hostsé verificado automaticamente para hosts conhecidos. Quaisquer novos hosts são adicionados automaticamente ao arquivo do usuário. Se a identificação de um host mudar, sshavisa sobre isso e desativa a autenticação de senha para impedir a falsificação do servidor ou ataques de intermediários, que poderiam ser usados ​​para contornar a criptografia. A StrictHostKeyCheckingopção pode ser usada para controlar logins em máquinas cuja chave do host não é conhecida ou foi alterada.

Parece que, na primeira opção, as teclas SSH estariam disponíveis no cartão SD. Assim, qualquer usuário pode pegar o cartão e lê-lo. Então, basicamente, suas chaves privadas se tornaram (principalmente) públicas.

Isso permitirá ataques man-in-the-middle, como o seguinte:

1. Um usuário configura um servidor SSH com as chaves privadas obtidas do seu dispositivo e fornece esse endereço IP ao seu técnico.
2. Seu técnico insere a senha de root na conexão SSH.
3. O usuário agora conhece a senha raiz que é válida para todos os seus dispositivos.

No entanto, você não deve usar senhas raiz, em primeiro lugar, use chaves ssh para autenticação. Em seguida, o impacto das chaves do servidor compartilhado será bem pequeno se você fizer logon apenas a partir de uma LAN.

O SSH também fornece sigilo de encaminhamento, portanto, um invasor deve ser capaz de configurar um servidor falso para se beneficiar das chaves; farejar passivamente o tráfego não permitirá descriptografá-lo.

Eu li isso horrorizado! Eu que fiz várias máquinas no mesmo cluster com a mesma chave de host ssh nunca ousaria fazer isso. Em nenhuma circunstância, permita que máquinas com diferentes conjuntos de administradores compartilhem chaves de host ssh. Dessa forma, há loucura e horror gritante quando você é postado por sua falta de segurança.

Eis que digo a verdade: quem compromete um dispositivo compromete todos eles. Uma vez obtido, espere que as pessoas más pulem de um para o outro à vontade e a segurança retroceda como se fosse papel fino.

Como você menciona que o acesso SSH não é usado pelo usuário / cliente final, convém desativar o acesso SSH por padrão e ativá-lo apenas temporariamente quando o dispositivo for colocado no modo "depuração".

Você pode enviar todos os dispositivos com a mesma chave, supondo que você tenha protegido o modo "depuração" para que não possa ser acionado remotamente por alguém tentando hackear o dispositivo.

Ou você tem uma nova chave gerada quando o dispositivo entra no modo "depuração" - para que você não precise perder o tempo de inicialização gerando as chaves cada vez que o dispositivo é ligado.

Aqui está um exemplo de cenário de ataque com base nas restrições que você possui:

Se os seus dispositivos estiverem, diga um Raspberry Pi, por exemplo. Se eu subir e arrancar o cartão SD de um, eu posso colocar o cartão SD no meu próprio computador, encontrar a chave sshd e copiá-la para onde quiser. Talvez eu pegue meu próprio raspberry pi e uma placa ethernet USB. Agora posso colocar isso entre um dispositivo de destino e onde quer que eles estejam e monitorar conexões ssh. Quando vejo que o dispositivo de destino está tentando fazer uma conexão ssh, faço o seguinte:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

Oh, o que é isso? Sua senha é "Eu gosto de gatos"? Rapaz, este é um e-mail interessante que você enviou para sua esposa. Aposto que seria ainda mais interessante se ela lesse esse e-mail que você enviou para a esposa do vizinho.

As possibilidades são infinitas . E o alvo nunca saberia, porque a chave sshd é idêntica à encontrada no servidor real. Dependendo da segurança física das instalações que estão recebendo seu dispositivo, isso pode ser incrivelmente trivial. Não faça isso.

Em vez disso, faça o que você já propõe, mas corrija-o . Antes de escrever sua imagem, execute algo como isto:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

E agora todo servidor tem uma nova chave. Porque você realmente, realmente não quer distribuir cópias de uma chave. Sinceramente, é pelo menos tão ruim quanto tirar uma foto das chaves da sua casa e enviá-las para a Internet com o seu endereço residencial.