Estamos tentando fazer uma AMI segura para distribuição a um de nossos clientes (executando Linux / CoreOS). Uma vez que nosso cliente implanta o nosso AMI, é importante que eles não consigam obter acesso ao shell (por exemplo, o SSH não pode entrar).
Na superfície, isso parece ser um problema muito simples de resolver: apenas certifique-se de que apenas as chaves estejam nos arquivos authorized_keys. No entanto, quando nosso cliente implanta nossa AMI, eles são forçados a fornecer seu próprio par de chaves e, em seguida, a chave pública associada é inserida no arquivo authorized_keys na caixa, habilitando-os para SSH na caixa.
Eu sei que a Amazon torna a chave pública acessível (e metadados do usuário) ao sistema operacional host via HTTP em 169.254.169.254 (informações aqui: link ). Algumas investigações na Internet e no sistema de arquivos CoreOS sugerem que os metadados / usr / bin / coreos realmente acessam esse IP, presumivelmente para o par de chaves, mas não consigo descobrir o que está realmente iniciando esse executável ou como desativá-lo. Eu até pensei em remover privilégios executáveis ou removê-los completamente, mas essa parte do sistema de arquivos é somente leitura no CoreOS (mesmo para o root).
Obviamente, o comportamento acima supera quaisquer medidas de segurança que implementamos. Existe alguma coisa que podemos fazer para evitar que isso aconteça?
cloud-init está fazendo isso. Desabilite sshd da execução (parte da sua compilação de AMI) e, em seguida, execute o código de script que coloca as chaves no lugar do usuário de login (é sugerido um diferente), inicie ssh . Sugiro também um número de porta diferente como uma maneira fácil de confirmar que você tem as coisas funcionando bem.