Acceso SSH externo a los servidores, con el nombre de dominio publico #23
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Acceder por SSH desde fuera con el nombre de dominio, a traves del proxy (Nginx ?) tiene varias ventajas
Ej.
Esto funciona en Nginx con un servidor (especificando ususario y otro puerto, distinto del 22)
PERO con mas de un servidor se confunde, enviando el stream al primero. Posiblemente sea porque el protocolo no carga el HOSTNAME por lo que el Proxy no sepa distinguir a qué servidor va. (a probar)
Un workaround podria ser asignar puertos distintos a cada servidor en el proxy, o si Nginx es el que no puede, usar otro proxy SSH, ojala en un unico puerto.
Comentamos que en caso de habilitarlo, hay que deshabilitar el login con password en los servers, solo dejando el login con llave SSH
Cuando se logra, para cambiar la configuraciones hay que
abra s add xxx.abyaya.laY ya se pueden ejecutar comandos abra normalmente
creo que es importante por seguridad pero hay que agregar en la planificacion la generacion de llaves y como mantenerlas seguras
habiamos hablado de usar tmate para tener sesión remota por ssh y web, sin necesidad de llaves ni contraseñas? claro que la url pasa a ser ultra secreta, sino da acceso a todo.
estoy pensando que en #54 el initramfs en vez de tener red+ssh+vpn, puede tener red+tmate y solo hay que saber la url para poder entrar y escribir la contraseña. tmate tambien soporta dar acceso a algunas llaves ssh, asi que tambien resolveria temas de acceso.
o sea el proxy reverso para ssh es un servidor de tmate en el proxy y las huertas tienen abierta una sesión permanente al proxy, sea desde el initramfs o desde el sistema ya booteado. les compas pueden tener "contraseña" solo sabiendo y compartiendo la url de tmate y/o acceso permitido solo a poques, teniendo llave ssh
No lo sé Rick. No estaremos mezclando mucho el gaspacho?
Por otro lado, tendríamos que tener un Tmate propio, y veo que no está en coopcloud
el proxy tampoco usa coopcloud, aunque podría hacer una receta. lo que me preocupa es que no tenga versiones hace 3 años, aunque en los issues el desarrollador parece que responde.
el cliente de tmate en las huertas corre como usuario del sistema (
administradorao lo que le pongamos).bueno, igual con dropbear en el initramfs y proxy reverso + puerto asignado estaríamos bien igual para desbloqueo remoto
que sea tmate o Nginx es aparte del desbloqueo remoto, no? quiero decir, igual para iniciar tmate antes hay que iniciar el sistema, con la contraseña de cifrado
tampoco estoy seguro si entiendo bien si el cliente tmate correria en cada huerta o uno solo en el proxy? en el segundo caso estarian damos a todxs acceso al proxy..
de todas maneras seria interesante hacer una prueba de esto para entenderlo bien,
el server tmate o nginx hacen de proxy reverso en el proxy para todas las huertas. o sea el cliente tmate se conecta al proxy y vos como amikiur te conectas por ssh/https al proxy, que te conecta transparentemente a la huerta.
la relación con el cifrado es que para desbloquear el disco cifrado necesitás que la huerta, desde el booteo, esté conectada a la vpn, para que el proxy se pueda conectar a través de nginx. con tmate en el initramfs, reemplazamos tener la vpn ahi también.
ahora me doy cuenta que reduce el riesgo de tener la llave privada de la vpn en el initramfs.
si queres probarlo, instalate tmate, correlo nomás con
tmate, copia las direcciones que te muestra en la pantalla y probalas desde otra computadora@Numerica fijate que te comenté el pr
Reabierto por causa de
b7139145dcEl bug se reproduce cuando es un servicio que no tiene definido ports (el puerto SSH especifico de cada server)
Con eso saltea si el service no tiene ports
En todo caso cada huerta debiera tener su puerto SSH diferente