O administrador do servidor me enviou uma chave privada para usar. Por quê?

Eu deveria estar acessando um servidor para vincular os servidores intermediários e ativos de uma empresa ao nosso ciclo de implantação. Um administrador do lado deles configurou as duas instâncias e, em seguida, criou um usuário no servidor para o SSH como. Estou acostumado com isso.

Na minha opinião, o que aconteceria agora seria enviar a minha chave pública, que poderia ser colocada dentro da pasta de chaves autorizadas. Em vez disso, no entanto, eles me enviaram um nome de arquivo id_rsaque dentro do arquivo contém -----BEGIN RSA PRIVATE KEY-----por email. Isso é normal?

Olhei em volta e posso encontrar toneladas de recursos para gerar e configurar minhas próprias chaves do zero, mas nada sobre como começar a partir das chaves privadas do servidor. Devo usar isso para gerar alguma chave para mim ou?

Gostaria de perguntar diretamente ao administrador do sistema, mas não quero parecer um idiota e desperdiçar todo mundo entre nós. Devo simplesmente ignorar a chave que ele me enviou e pedir que eles coloquem minha chave pública na pasta autorizada?

— Toby
fonte

Eu não chamaria isso de normal ou sensato, mas como você possui a chave privada (supondo que eles já a tenham adicionado como autorizada), você pode usá-la como qualquer outra chave privada. Você não precisa a chave pública correspondente, mas se você quiser, você sempre pode gerá-lo: askubuntu.com/a/53555/158442

— Muru

Superar -----BEGIN RSA PRIVATE KEY-----email é a próxima coisa assustadora depois de ver um usuário nomeado '); DROP DATABASE;--na sua tabela de nome de usuário.

— Dmitry Grigoryev

@DmitryGrigoryev nada assustador sobre vendo '); DROP DATABASE;--como um nome de usuário na sua tabela de banco de dados - mostra que você está escapando entrada do usuário corretamente

— HorusKol

Você certamente não pode 'usá-lo como usaria qualquer outra chave privada'. Este não é privado. Logo , não é possível cumprir a função para a qual foi criado. Ele deve ser jogado fora e o administrador do UNIX severamente castigado. @muru

— user207421

Qualquer pessoa que possua essa chave privada tem acesso aos novos servidores. Presumivelmente, o administrador tem acesso de qualquer maneira sem precisar da chave, visto que ele foi capaz de configurar o servidor, portanto não há ameaça adicional de acesso não autorizado por ele. No entanto, como essa é sua chave, ele agora pode se passar por você com segurança. Há também a chance de alguém que não seja você ler o e-mail, e eles também podem se passar por você.

— precisa saber é o seguinte

Respostas:

116

Na minha opinião, o que aconteceria agora seria enviar a minha chave pública, que poderia ser colocada dentro da pasta de chaves autorizadas.

O que está "em sua mente" como o que deve agora acontecer está correto.

O email não é um canal de comunicação seguro; portanto, do ponto de vista da segurança adequada, você (e eles) deve considerar que a chave privada está comprometida.

Dependendo da sua habilidade técnica e do quão diplomático você deseja ser, você pode fazer várias coisas diferentes. Eu recomendaria um dos seguintes:

Gere seu próprio par de chaves e anexe a chave pública a um e-mail enviado a eles, dizendo:

Obrigado! Como o email não é um método de distribuição seguro para chaves privadas, você poderia colocar minha chave pública no lugar? Está anexado.
Agradeça a eles e pergunte se eles se opõem a que você instale seu próprio par de chaves, pois a chave privada que eles enviaram deve ser considerada comprometida após o envio por email.

Gere seu próprio par de chaves, use a chave que eles enviaram para efetuar logon pela primeira vez e use esse acesso para editar o authorized_keysarquivo para conter a nova chave pública (e remover a chave pública correspondente à chave privada comprometida).

Conclusão: você não parecerá um idiota. Mas, o outro administrador pode parecer muito idiota. Uma boa diplomacia poderia evitar isso.

Edite em resposta aos comentários do MontyHarder:

Nenhum dos meus cursos de ação sugeridos envolve "consertar as coisas sem dizer ao outro administrador o que ele fez de errado"; Eu o fiz sutilmente sem jogá-lo debaixo do ônibus.

No entanto, acrescentarei que também acompanharia (educadamente) se as pistas sutis não fossem captadas:

Olá, vi que você não respondeu ao meu comentário sobre o email como um canal inseguro. Eu quero ter certeza de que isso não acontecerá novamente:

Você entende por que estou falando sobre o manuseio seguro de chaves privadas?

melhor,

Toby

— Curinga
fonte

+1 Melhor resposta. E eu acrescentaria: tenha um cuidado especial, pois esse administrador de sistemas provou ser incompetente. É melhor ter as costas cobertas quando (e não se ) ele / ela estragar o servidor para sempre.

— dez01

Obrigado. Usei algumas frases delicadas e enviei minha chave pública. Tudo parece resolvido, mas vou desautorizar a chave que ele me enviou agora.

— Toby

Não é que o outro administrador "possa parecer um idiota". É que o outro administrador fez algo idiota. Só consigo pensar em um cenário em que uma chave privada deve ser compartilhada entre máquinas, e é aí que um pool de servidores é acessado pelo mesmo nome (resolução DNS round-robin etc.) e deve apresentar a mesma chave de host SSH para que processos automatizados aceitarão que eles são esse nome. E, nesse caso, a mesma pessoa seria um administrador de todos os servidores e lidaria com as transferências sem que uma parte externa estivesse envolvida.

— Monty Harder,

@zwol No meu trabalho, temos uma filosofia de "não culpar" que entende que cometeremos erros, mas que é uma alta prioridade não cometer o mesmo erro duas vezes. Mas, para não cometer o mesmo erro duas vezes, você deve saber que é um erro, e é por isso que não posso votar novamente nas respostas que sugerem que o OP conserte as coisas sem dizer ao outro administrador o que ele fez de errado. Eu escolhi chamar o erro de "idiota" em vez de chamar os nomes dos administradores precisamente pelo motivo que você descreve. (Mas eu não tenho certeza de que seu parenthetical final articula uma distinção significativa.)

— Monty Mais difícil

@LightnessRacesinOrbit, suspeito que você tenha um entendimento incompleto do significado de "diplomacia". Você já tentou esclarecer isso em um bom dicionário, como o Terceiro Novo Dicionário Internacional do Webster?

— Curinga

Devo simplesmente ignorar a chave que ele me enviou e pedir que eles coloquem minha chave pública na pasta autorizada?

Sim, é exatamente isso que você deve fazer. O ponto principal das chaves privadas é que elas são privadas , o que significa que apenas você tem sua chave privada. Desde que você recebeu essa chave do administrador, ele também a possui. Para que ele possa se passar por você quando quiser.

Se a chave foi enviada a você por um canal seguro ou não, é irrelevante: mesmo que você tenha recebido sua chave privada pessoalmente, isso não mudaria nada. Embora eu concorde com os comentários de que enviar chaves de criptografia confidenciais por e-mail é a cereja do bolo: seu administrador nem mesmo finge que existe algum tipo de política de segurança em vigor.

— Dmitry Grigoryev
fonte

E como o OP não tem como saber o quão segura é a máquina do administrador (da história, presumivelmente muito insegura), ele deve assumir que a chave privada é (ou será) também vazou para outras pessoas. O envio de uma chave privada por e-mail é apenas um fato adicional para a infosec sem noção.

— 01

Você pode supor que um administrador capaz de criar usuários não precisará da sua chave privada para se passar por você.

— Max Ried

@MaxRied Isso pode ser difícil de fazer com os logs de segurança adequados. Com sua chave privada, ele nem precisa zombar dos logs. É como ter a capacidade de redefinir sua senha versus conhecê-la.

— Dmitry Grigoryev

@DmitryGrigoryev Ele poderia sempre adicionar outra chave para o seu arquivo authorized_keys ...

— Max Ried

@ MaxRied eu estava me referindo /var/log/secureou similar , tenho certeza que o truque espacial não vai enganar este.

— Dmitry Grigoryev

Para mim, parece que o administrador gerou um par de chaves pública / privada para você, adicionou a chave pública às chaves_autorizadas e enviou a você a chave privada. Dessa forma, você só precisa usar essa chave privada para suas sessões ssh com o servidor. Não é necessário gerar você mesmo um par de chaves ou enviar ao administrador uma chave pública para sua chave privada possivelmente corrompida (sempre pense no pior caso: P).

No entanto, eu não confiaria na chave privada enviada a você por email não criptografado.

Minha abordagem seria: use a chave privada para efetuar login uma vez, adicione sua própria chave pública às chaves_estabelecidas no servidor (substituindo a chave pública original) e jogue fora essa chave privada de email. Você pode então agradecer ao administrador que ele / ela forneceu a chave privada, mas você prefere que essas informações / chaves não sejam enviadas por email (/ de todo).

— user204269
fonte

@ Toby A única razão pela qual posso imaginar o envio da chave privada é que eles não entendem as ferramentas que estão usando. E você pode usar -ina linha de comando para escolher qual chave privada usar.

— precisa saber é o seguinte

@kasperd A razão que eu posso imaginar é um sysadmin sobrecarregado que decidiu que os riscos de envio de uma chave privada por e-mail são superados pelo aborrecimento de tentar explicar aos usuários menos-savvy tecnologia como gerar corretamente um par de chaves e enviar o chave pública de volta.

— amigos estão dizendo sobre mattdm

Ótimo ponto que você pode consertar isso sozinho. É melhor fazer você mesmo imediatamente do que esperar o administrador instalar a chave pública para um novo par de chaves. Evitar usar a chave privada não mais secreta não ajuda em nada; ele apenas fornece a possíveis bisbilhoteiros mais tempo para usá-lo antes que você possa entrar e removê-lo authorized_keys(depois de adicionar + testar o seu próprio).

— Peter Cordes

@mattdm Isso ... é totalmente lógico, mas assustador. Uma pessoa que não pode gerar um par de chaves e me enviar a chave pública provavelmente não vai se sair muito melhor com uma chave privada que eu lhe dou.

— Monty Mais difícil

@mattdm, justo o suficiente, mas como eu pedi para ele fazer tudo isso, acho difícil acreditar que ele pensasse que eu não sabia como conectar-me ao ssh. De qualquer forma, os passos que ele tomou foram mais confusos, pois eu só conheço a maneira básica básica de usar chaves públicas. : x

— Toby