Túnel SSH como cifrado y autenticación para servicio local

Túnel SSH como cifrado y autenticación para servicio local

Fondo:

En mi servidor hay un servicio en ejecución que escucha en un socket de dominio /srv/socketlas conexiones entrantes y luego interactúa con el usuario que se conectó. Tenga en cuenta que este servicio es uno que escribí (en C++), por lo que puedo modificar el comportamiento del servicio con bastante facilidad. En este momento, este servicio no realiza autenticación ni verificación de permisos (como verá en un segundo, esto tendrá que cambiar). Algunos desarrolladores (creo que entre cinco y diez) con los que estoy trabajando necesitan acceso a este servicio (y solo a este servicio) desde computadoras en algún otro lugar de Internet. Debido a que este servicio les otorga bastantes privilegios, quiero que la autenticación sea lo más sólida posible y que la conexión esté cifrada. La pregunta subyacente que tengo (para evitar cualquier problema XY) es: ¿Cómo configuro esto?

Idea y preguntas al respecto:

Mi idea original era proporcionar mi propia autenticación y luego usar TLS para el cifrado (exponiendo el servicio en un puerto externo, por supuesto). Sin embargo, escribir mi propia autenticación probablemente genere fallas de seguridad, y configurar la conexión para que funcione a través de TLS será una molestia.

Mi segunda idea fue entonces usar SSH. SSH ya tiene autenticación y cifrado muy sólidos y básicamente hace lo que necesito. Lamentablemente, no estoy muy seguro de cómo configurar esto. Primero, por supuesto, no quiero darles a los desarrolladores acceso completo al shell, por lo que cambiaré su shell predeterminado a /bin/false(según algunas otras respuestas en este y otros sitios relacionados). Pero todavía los necesito para poder conectarlos al enchufe correspondiente. Miré el túnel ssh pero eso no parece ser lo que necesito, y otras búsquedas de cosas similares a "ssh como proxy" revelan problemas relacionados pero no idénticos. ¿Qué es lo correcto que se debe hacer aquí? Por supuesto, podría escribir un ejecutable personalizado que actuará como un "shell" y simplemente conectará a esos usuarios a mi servicio, pero nuevamente, este código será sensible a la seguridad y, cuando sea posible, me gustaría evitar escribir el mío propio.

En el mejor de los casos:

Idealmente, me gustaría que sucediera lo siguiente:

  1. El usuario ejecuta algún comando en su cliente.
  2. Se crea una conexión cifrada a un servicio proxy en mi servidor y el usuario se autentica en este servicio (idealmente, este es un servicio bien establecido que se sabe que es razonablemente seguro).
  3. El servicio proxy abre una conexión a mi servicio, reenvía el nombre de usuario (o algún identificador de usuario) y conecta al cliente.

¿Cuál es la mejor manera de hacer esto?

Respuesta1

Sé que ha pasado un tiempo desde tu pregunta, pero en caso de que todavía estés interesado, echa un vistazo a micorreoen Fallo del Servidor. Si bien el problema no está relacionado con sus necesidades, la solución que propongo puede ser directamente relevante. Esperaba obtener algunas respuestas a esa publicación de expertos que entienden las implicaciones de seguridad mejor que yo, pero eso no ha sucedido.

La publicación es un poco larga para replicarla aquí, pero en pocas palabras este es el concepto:

  • configure SSH para requerir tantos mecanismos de autenticación que necesite o pueda tolerar, por ejemplo, contraseña + claves + otp, etc.
  • establezca el shell de usuario en /sbin/nologin( /sbin/nologinse prefiere sobre /bin/false)
  • utilice sshrc en el servidor para llamar a un script cuando el usuario se conecta (autentica) a través de ssh, el script puede hacer lo que necesite, por ejemplo, iniciar su servicio

En la configuración anterior, sus usuarios se autentican a través de SSH y, una vez autenticados, /etc/ssh/sshrchacen lo necesario para su servicio y /sbin/nologindesconectan elegantemente la sesión SSH posterior a la autenticación, ya que ya no es necesaria.

Puedes volverte loco con el script en sshrc. Por ejemplo, considere comenzar sin puertos abiertos para su servicio. Una vez que un usuario se autentica, el script sshrc puede abrir un puerto para la IP del usuario en su firewall sobre la marcha.

Tenga en cuenta:Lo anterior supone que usted realmente sabe lo que está haciendo con respecto a la configuración de ssh. Si bien existen varias implementaciones de SSH bien probadas, muchas de ellas se pueden configurar mal fácilmente con importantes implicaciones de seguridad. Además, para la autenticación SSH, recomiendo encarecidamente utilizar siempre las claves + (al menos una cosa que el usuario sepa, por ejemplo, contraseña u otp, idealmente ambas).

información relacionada