Tunelamento SSH como criptografia e autenticação para serviço local

Question

Fundo:

No meu servidor, há um serviço em execução que escuta em um soquete de domínio /srv/socketconexões de entrada e, em seguida, interage com o usuário conectado. Observe que este serviço foi escrito por mim (em C++) para que possa modificar o comportamento do serviço com bastante facilidade. No momento, nenhuma autenticação ou verificação de permissão é feita por este serviço (como você verá em um segundo, isso terá que mudar). Alguns desenvolvedores (pense em cinco a dez) com quem estou trabalhando precisam de acesso a este serviço (e apenas a este serviço) de computadores em algum outro lugar na Internet. Como este serviço lhes dá alguns privilégios, quero que a autenticação seja o mais forte possível e que a conexão seja criptografada. A questão subjacente que tenho (para evitar qualquer problema XY) é: Como faço para configurar isso?

Idéia e perguntas sobre isso:

Minha ideia original era fornecer minha própria autenticação e depois usar TLS para criptografia (expondo o serviço em uma porta externa, é claro). No entanto, escrever minha própria autenticação provavelmente levará a falhas de segurança, e configurar a conexão para funcionar por TLS será uma dor.

Minha segunda ideia foi apenas usar SSH. O SSH já possui autenticação e criptografia muito fortes e basicamente faz o que eu preciso. Infelizmente, não tenho certeza de como configurar isso. Primeiro, é claro que não quero dar aos desenvolvedores acesso total ao shell e, portanto, alterarei o shell padrão para /bin/false(conforme algumas outras respostas neste e em sites relacionados). Mas ainda preciso que eles possam se conectar ao soquete relevante. Eu pesquisei o tunelamento ssh, mas isso não parece ser o que eu preciso, e outras pesquisas por coisas semelhantes a "ssh como proxy" revelam problemas relacionados, mas não idênticos. Qual é a coisa certa a fazer aqui? Claro, eu poderia escrever um executável personalizado que atuaria como um "shell" e simplesmente conectaria esses usuários ao meu serviço, mas, novamente, esse código será sensível à segurança e, sempre que possível, gostaria de evitar escrever o meu próprio.

Melhor cenário possível:

Idealmente, gostaria que acontecesse o seguinte:

1. O usuário executa algum comando em seu cliente.
2. Uma conexão criptografada com um serviço proxy em meu servidor é criada e o usuário se autentica nesse serviço (idealmente, este é um serviço bem estabelecido e conhecido por ser razoavelmente seguro).
3. O serviço proxy abre uma conexão com meu serviço, encaminha o nome de usuário (ou algum identificador de usuário) e conecta o cliente.

Qual é a melhor maneira de fazer isso?

Answer 1

Eu sei que já faz algum tempo desde a sua pergunta, mas caso você ainda esteja interessado, dê uma olhada no meupublicarem falha do servidor. Embora o problema não esteja relacionado às suas necessidades, minha solução proposta pode ser diretamente relevante. Eu esperava obter algumas respostas a essa postagem de especialistas que entendem as implicações de segurança melhor do que eu, mas isso não aconteceu.

A postagem é um pouco longa para replicar aqui, mas em poucas palavras este é o conceito:

• configure o SSH para exigir quantos mecanismos de autenticação você precisar/puder tolerar, por exemplo, senha + chaves + otp, etc.
• defina o shell do usuário como /sbin/nologin( /sbin/nologiné preferível /bin/false)
• utilize sshrc no servidor para chamar um script quando o usuário se conecta (autentica) via ssh, o script pode fazer o que você precisar, por exemplo, iniciar seu serviço

Na configuração acima, seus usuários são autenticados via SSH e, uma vez autenticados, /etc/ssh/sshrcfazem o necessário para seu serviço e /sbin/nologindesconectam normalmente a sessão SSH após a autenticação, uma vez que ela não é mais necessária.

Você pode enlouquecer com o script no sshrc. Por exemplo, considere começar sem nenhuma porta aberta para o seu serviço. Depois que um usuário é autenticado, o script sshrc pode abrir uma porta para o IP do usuário em seu firewall instantaneamente.

Observe:o que foi dito acima pressupõe que você realmente sabe o que está fazendo em relação à configuração do ssh. Embora existam várias implementações de SSH bem testadas, muitas delas podem ser facilmente configuradas incorretamente, com grandes implicações de segurança. Além disso, para autenticação SSH, recomendo sempre usar chaves + (pelo menos uma coisa que o usuário saiba, por exemplo, senha ou otp, de preferência ambos).