Eu quero delegar a autenticação baseada em pubkey para um determinado usuário para um servidor SSH diferente, sem modificar a configuração do cliente, mas permitindo modificações no software do servidor.
Já existem várias perguntas semelhantes. Este e este solicite o envio com base no nome do host em vez do nome do usuário. Este e este ssh , então isso só usará chaves públicas no destino final se o encaminhamento do agente estiver habilitado. Esta questão aqui é mais específica sobre como alcançar o objetivo declarado.
Li a RFC 4251 seção 1 . De acordo com isso, existem três layes na pilha SSH. A camada TRANS (transporte) fornece integridade e autenticação do servidor. A camada USERAUTH (autenticação do usuário) faz a autenticação do usuário e a camada CONNECT (conexão) multiplexa os dados reais da carga útil. Então eu quero um homem na interceptação do meio na camada TRANS, enquanto encaminha as camadas USERAUTH e CONNECT.
client proxy server
CONNECT X-----------X
USERAUTH X-----------X
TRANS X---X X---X
TCP X---X X---X
Como a camada TRANS faz autenticação do servidor, o cliente obviamente veria a chave pública do proxy, o que é aceitável no meu aplicativo. De acordo com a RFC 4252 seção 1 , a camada USERAUTH recebe um formulário identificador de sessão na camada TRANS. O que significa que o servidor real provavelmente precisaria de algum recurso adicional para poder usar o identificador de sessão negociado entre o cliente e o proxy, em vez daquele que foi negociado com o proxy.
Isso pode ser feito?
Existe alguma implementação conhecida de tal esquema?
Ou há algo que eu negligenciei, alguma razão pela qual isso não pode funcionar mesmo se alguém tiver controle sobre o software em execução no proxy e no servidor?
Vários serviços vêm como imagens Docker prontas para uso que fornecem acesso git sobre ssh a seus dados, de uma forma ou de outra. Geralmente, todo o acesso é feito usando uma única conta, usando chaves públicas para realmente distinguir os usuários. Então, passar a chave pública é vital.
É possível expor esses serviços usando portas diferentes. Mas o uso de portas privilegiadas para serviços diferentes dos registrados pode ser visto como um estilo ruim, usando portas não privilegiadas como um risco de segurança e, em geral, os nomes de usuários são muito mais memoráveis do que os números de porta. Além disso, um nome de usuário é obrigatório, mesmo que seja apenas git . Não exigir um número de porta não padrão permite usar a menor notação de ‹user›@‹host›:‹path› de repositórios git, em oposição ao mais demorado ssh://‹user›@‹host›:‹port›/‹path› .
Eu duvido que quaisquer imagens comuns do Docker façam uso de algo assim. Mas, se fosse possível, poder-se-ia sugerir a adição das alterações necessárias do servidor a essas imagens, para que abordagens como essa se tornassem viáveis no futuro.
Tags ssh reverse-proxy public-key