Entra un ticket. El sitio de un cliente lanza un error que solo ocurre en producción, de esos que no se reproducen en ningún otro lado, y quien de verdad conoce el código es su desarrollador — o el ingeniero de soporte del proveedor de un plugin, o el freelance que armó la cosa hace dos años. Sea quien sea, no trabaja para ti, y el arreglo vive en un servidor del que tú eres responsable.
Ahora tienes que decidir cómo entra. Y cada instinto que tienes es malo.
Las opciones que tienes hoy son apuestas que vas a perder
Compartir root. Rápido, y catastrófico. Esa contraseña ahora vive en el gestor de contraseñas de otra persona, en su historial de chat, quizá en un post-it. No caduca. No rota. Cuando ese trabajo termine — o cuando a ese proveedor lo comprometan — la credencial sigue siendo válida y nunca te vas a enterar de que se filtró. Entregaste una llave permanente a un problema temporal.
Crear un usuario SSH temporal. Mejor, en teoría. En la práctica acabas montando una pequeña burocracia: generar una llave, acotar el sudoers, acordarte de borrarlo cuando terminen. Ese último paso es el que nunca pasa. Seis meses después tu /etc/passwd es un cementerio de support-acme, dev-temp, vendor2 — cada uno una puerta olvidada, ninguno auditado.
Compartir pantalla y dictar comandos. Seguro, y miserable. Convertiste a un ingeniero senior en un par de manos remotas que teclean lo que alguien dicta por una llamada, equivocándose en la mitad, durante una hora. El tiempo de nadie vale esto.
Lo que las tres tienen en común: confunden operar el servidor con tener una credencial del servidor. Tú solo quieres conceder lo primero. Las herramientas te obligan a conceder lo segundo.
Una invitación da acceso sin dar una credencial
CentralHost separa esas dos cosas. El invitado nunca toca una llave SSH ni la contraseña de root. Lo que le entregas es un link de invitación de un solo uso a un único terminal — y el privilegio lo tiene el plano de control de la plataforma, no la persona que hace clic en el link.
El modelo es deliberadamente estricto: una invitación = un terminal = una sentada.
Abres el diálogo Invitar a soporte en la sección Terminal del servidor, respondes una pregunta — ¿para quién es este acceso? (ej. “Maya — soporte de AcmeDev”) —, eliges una duración máxima de sesión de un preset (15m, 30m por defecto, hasta unas horas), y obtienes un link. Esa etiqueta no es decoración: se convierte en el título de la grabación, así que la pista de auditoría dice “Soporte externo · Maya — AcmeDev” y no un blanco anónimo.
Copias ese link y se lo envías a la persona por tu propio canal — el hilo de correo o el chat donde ya tienes una relación con ella. CentralHost no le manda un correo a un desconocido frío en tu nombre; la confianza en esa entrega es tuya, y no nos metemos en medio.
Dos relojes, para que un link olvidado no te persiga
Hay dos temporizadores independientes, y la distinción es justo el punto:
- El link tiene una ventana para ser abierto. Lo envías, y si nadie lo canjea, caduca en silencio. Una invitación que nunca se usa no se puede usar después.
- El reloj de sesión arranca en el primer connect. En el momento en que el invitado abre el terminal, el token queda quemado — canjeado exactamente una vez — y su tiempo máximo de sesión empieza a correr hacia abajo.
Así que un link durmiendo en una bandeja de entrada durante una semana no es un riesgo permanente. O se abre pronto, en tu reloj, o está muerto. No hay escenario en el que una invitación rancia se convierta en una puerta viva dentro de seis meses.
Para los detallistas de seguridad: el token viaja en el fragmento de la URL (la parte después del #), que los navegadores nunca envían al servidor. El secreto que concede la sesión vive solo en el link mismo, y de nuestro lado solo se guarda su SHA-256.
Cerrar el terminal es lo mismo que terminar la sesión
Esta es la regla que hace que todo el asunto sea seguro de entregar: cerrar consume la sesión. exit en el shell, cerrar la pestaña, un refresh, incluso que se caiga la conexión — cualquiera de ellos quema la ventana. El hub de control recorta el vencimiento de la sesión en el instante en que el invitado se desconecta, así que el mismo link no reconecta. Una sentada, y se gastó.
Significa que no tienes que confiar en que el invitado “cierre sesión correctamente”. No queda una sesión colgando por limpiar, ni una puerta entreabierta. Hace el trabajo, cierra la pestaña, y el acceso desapareció. Si de verdad necesita volver, eso es una nueva invitación — un acto deliberado de tu lado, no un token reusado del suyo.
Tú conservas los controles todo el tiempo
El invitado opera, pero tú tienes la perilla:
- Extender en vivo. ¿Subestimaste el trabajo? Mientras la sesión esté viva (o en una breve gracia tras vencer), súmale minutos desde el mismo diálogo — el link del invitado sigue funcionando, solo se mueve el reloj. Estás recargando tiempo, no reemitiendo acceso.
- Kill switch. ¿Algo se ve mal? Revócalo, y el hub no solo bloquea el próximo connect — dropea el PTY en vivo. Un watchdog re-chequea cada pocos segundos, así que un revoke cae sobre una sesión en curso, no solo sobre la siguiente.
- Un link muerto sigue muerto. La revocación es un estado final. Puedes extender una sesión viva, pero no resucitar una gastada o revocada — para otra ocasión, emites una invitación nueva. No hay un “reactivar” que encienda en silencio un link viejo.
Y todo queda registrado
Como este es el mismo terminal del plano de control que usan tus propios operadores, una sesión de invitado se graba exactamente igual que cualquier otra — las teclas, la salida, el tiempo, reproducible después en la sección Auditoría del servidor. (Así funciona esa grabación, y por qué secretos como la contraseña de un mysql -p se redactan fuera de ella.)
La diferencia es el rótulo. Un invitado no tiene identidad de cuenta, así que la grabación lleva un chip “Invitado” donde iría el nombre del operador, más la etiqueta que pusiste al invitar. Dos semanas después, cuando tú — o el cliente — pregunten ¿qué hizo de verdad ese proveedor en la caja?, la respuesta no es un encogimiento de hombros. Es una reproducción, atribuida, titulada e imposible de falsear para el invitado, porque se capturó en el hub y nunca en el servidor que estaba tocando.
El invitado también lo ve venir. Su pantalla no tiene chrome — solo el terminal, sin sidebar, sin cuenta, un claro “invitado por {tu empresa}” y un contador en vivo — y antes de la primera tecla hay un gate de consentimiento de un clic: esta sesión puede grabarse con fines de auditoría. Sin sorpresas, sin ambigüedad. Sabe que es un invitado en una sala grabada, y lo aceptó.
El punto
El soporte externo es una parte normal de operar servidores ajenos. El error es tratar “dejarlo entrar” como un problema de credenciales, porque las credenciales son permanentes y las personas son temporales — y ese desajuste es justo de donde salen las contraseñas filtradas y las cuentas dev-temp olvidadas.
CentralHost lo trata como un problema de acceso. Un link, un terminal, una sentada. Caduca solo, puedes terminarlo antes, el invitado nunca tiene una llave de tu servidor, y cada segundo queda registrado con su nombre encima. Le diste el trabajo. Nunca entregaste las llaves.