Son las 2am. Un sitio está caído, entras por SSH y veinte minutos después está arreglado. Editaste un config, reiniciaste un servicio, ajustaste un límite, corriste un comando suelto que no volverías a escribir. Cierras el terminal y vuelves a dormir.
Dos semanas después, algo en ese servidor se comporta raro, y la única pregunta que importa es ¿qué cambié esa noche? Vuelves a entrar a la caja y empiezas a reconstruirlo de memoria. Quizá history ayude. Probablemente no.
Aquí está la parte incómoda: SSH no guardó ninguna copia de esa noche. Una sesión de shell es un transporte, no un registro. Cuando la conexión se cierra, los bytes se van: los comandos, su salida, el orden en que corrieron, el momento exacto en que la cosa se rompió. El único registro que queda es tu memoria, y tu memoria no es un registro.
Por qué history no es la respuesta
El reflejo habitual es “para eso está el historial del shell”. No lo es, y vale la pena ser preciso sobre por qué:
- Guarda comandos, nunca salida. ¿El
tailque te mostró la pista clave? Se fue. Te quedaste con la pregunta, no con la respuesta. - Es por usuario y editable. Cualquiera con el shell puede
history -c, o anteponer un espacio para mantener un comando fuera de él. Un registro que el sujeto puede editar no es una pista de auditoría. - No tiene ni tiempo ni resultado. No puedes distinguir qué corrió a las 2:14 frente a las 2:40, ni si el comando funcionó: solo que se tecleó en algún momento.
Nada de eso es un defecto de SSH. SSH nunca intentó recordar nada. La memoria tiene que vivir en otra parte.
Lo que CentralHost graba en su lugar
En CentralHost el terminal web no es un socket crudo a la caja: pasa por un plano de control, y cada sesión de operador abierta desde la plataforma se graba mientras ocurre. No los comandos que recuerdas haber tecleado: la sesión real.
La vista de auditoría de cada servidor las lista, las más recientes primero: quién la abrió, desde qué IP, cuándo, cuánto duró, cómo terminó:
Una sesión viva aparece como En vivo mientras está abierta. Una que cayó por el idle-timeout de 30 minutos lo dice. Una que superó el tope de tamaño se marca truncada en vez de fingir en silencio estar completa. El registro está hecho para ser honesto sobre sus propios huecos, porque un log que exagera es peor que ninguno.
La reproducción es lo que sorprende
Una lista de sesiones es útil. Reproducir una es lo que nadie espera en un hosting web.
Las grabaciones se guardan en formato asciicast — los bytes y su tiempo —, así que una reproducción no es un volcado de texto plano. Es la sesión misma, reproducida: el repintado de top, las barras de progreso, cada comando y la salida que produjo, en el orden y al ritmo en que realmente pasó.
Mira la línea mysql -u root -p. La contraseña no está en la grabación: es ‹redactado›. Mientras el terminal tiene el eco apagado (un prompt de contraseña, sudo, ssh, passwd), las teclas se descartan y se reemplazan por un único marcador. Ni el secreto, ni su longitud, ni el tiempo por tecla. Esa redacción es lo que hace que la grabación sea segura de conservar: obtienes una reproducción fiel del trabajo sin un cofre de contraseñas en claro durmiendo en tu log de auditoría.
Y si prefieres grep antes que mirar, cada grabación también se proyecta a un transcript de texto plano: una proyección orientada a líneas de la pantalla, con las barras de progreso colapsadas a su estado final y las apps de pantalla completa como vim/htop filtradas. La misma grabación, dos vistas: la miras o la buscas.
Es un registro, no una cámara sobre tu hombro
Esta es la objeción que conviene responder de frente: ¿no es esto vigilar a mi propio equipo?
No, y la prueba es que vale igual cuando eres el único sysadmin. El valor no es atrapar a quién fue. Son tres cosas que nada tienen que ver con la desconfianza:
- Memoria. El problema de “2am, dos semanas después” del inicio de este post. Un operador solo olvida su propio trabajo; la grabación no.
- Evidencia. Cuando un servidor se compromete, las grabaciones separan “esta fue mi sesión” de “esto no fui yo”. El registro exculpa con la misma facilidad con que señala — sobre todo cuando quien pregunta es un cliente.
- Continuidad. El día que entra un segundo operador, la pista ya está. No la improvisas tras el primer “espera, ¿quién tocó esto?”.
Y como la grabación se captura en el hub de control, no en el servidor, el sujeto no puede falsearla. Un root en la caja puede borrar su propio history; no puede meter la mano en el log de auditoría y editar lo que el hub ya escribió. El registro es independiente de la persona que registra.
Lo que cuesta conservarlo
Las grabaciones se comprimen y se cifran por empresa, y luego caducan según una ventana de retención que tú defines (10 días por defecto). ¿Diste con una que quieres conservar — una migración complicada, un incidente que merece post-mortem? La anclas con la estrella; las grabaciones ancladas quedan exentas del borrado automático. Una barra de almacenamiento muestra el footprint para que la pista de auditoría nunca se coma el disco en silencio.
El punto
Ya haces trabajo cuidadoso en estos servidores. Lo que no tienes, con una sesión SSH pelada, es nada que mostrar a la mañana siguiente: ni a ti, ni a un compañero, ni a un cliente. La sesión fue real; el registro de ella se evaporó.
SSH nunca iba a recordar lo que hiciste esa noche. La plataforma por la que lo corres debería — y en CentralHost lo hace, por defecto, con los secretos fuera.