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

Question

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

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

Minhas duas opções, conforme as vejo, são:

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

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

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

Fazer o login com o 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 de usar as mesmas chaves do servidor em vários dispositivos de hardware?

PS alguém poderia criar uma tag internet-of-things?

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

Eu sei que esta é provavelmente uma má ideia. Eu gostaria de saber porque precisamente é uma má idéia, então eu posso entender as compensações.

    

Answer 1

Em vez de armazenar dados específicos do host, como chaves de host ssh no cartão SD ou outra mídia somente leitura, é possível armazenar isso em NVRAM, que é o que é para um sistema embarcado. Você precisará fazer alguns scripts personalizados para armazenar e recuperar as chaves no momento da inicialização, mas os scripts serão exatamente os mesmos para todos os dispositivos.

    

Answer 2

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 isso significa que não há nenhuma maneira (de um cliente SSH) de identificar exclusivamente o dispositivo conectando à. Caso seu par de chaves vaze, ele pode ser usado para ataques MITM.

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

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

ssh automatically maintains and checks a database containing identification for all hosts it has ever been used with. Host keys are stored in ~/.ssh/known_hosts in the user's home directory. Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any new hosts are automatically added to the user's file. If a host's identification ever changes, ssh warns about this and disables password authentication to prevent server spoofing or man-in-the-middle attacks, which could otherwise be used to circumvent the encryption. The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed.

    

Answer 3

Parece que na primeira opção, as chaves SSH estarão disponíveis no cartão SD. Assim, qualquer usuário poderia 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 os seguintes:

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

No entanto, você não deveria estar usando senhas root, em primeiro lugar, use as chaves ssh para autenticação. Em seguida, o impacto das chaves do servidor compartilhado é muito pequeno se você fizer logon apenas em uma LAN.

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

    

Answer 4

Eu li isso em horror! Eu que fiz várias máquinas no mesmo cluster com a mesma chave de host ssh nunca ousaria fazer isso. Não permita que máquinas com diferentes conjuntos de administradores compartilhem chaves de host ssh. Dessa forma, fica a loucura e o terror quando você é informado por sua falta de segurança.

Eis que eu te digo a verdade, aquele que compromete um dispositivo compromete todos eles. Uma vez obtida, espere que pessoas ruins pulem de um para outro à vontade e a segurança reverta como se fosse papel fino.

    

Answer 5

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

Você pode enviar todos os dispositivos com a mesma chave, desde que você tenha protegido o modo "debug" para que não seja acionado remotamente por alguém que esteja tentando hackear o dispositivo.

Ou você tem uma nova chave gerada quando o dispositivo entra no modo "debug" - assim você não precisa desperdiçar o tempo de inicialização gerando as chaves toda vez que o dispositivo é ligado.

    

Answer 6

Veja um exemplo de cenário de ataque com base nas restrições que você tem:

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

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

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

As possibilidades são infinitas . E o alvo nunca saberia, porque a chave sshd é idêntica àquela 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ôs, mas corrija-o . Antes de escrever sua imagem, execute algo assim:

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 todos os servidores têm uma nova chave . Porque você realmente, realmente não quer distribuir cópias de uma chave. Quero dizer honestamente, é 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.