Acceso SSH que se cierra solo: por qué lo hicimos así
Publicado el 2026-09-12 por frfrand
El problema no es abrir el acceso, es acordarse de cerrarlo. Cómo funciona un acceso con fecha de vencimiento y qué cambia en la práctica cuando pedir permiso deja de tener consecuencias permanentes.
Todo equipo tiene una versión de esta historia.
Alguien necesitó entrar al servidor un martes a la tarde. Se abrió el acceso. El problema se resolvió. Y el acceso quedó abierto, porque cerrarlo no era urgente para nadie, y lo urgente siempre le gana a lo importante.
Seis meses después, nadie se acuerda de que está abierto. Y ahí es donde deja de ser una anécdota.
El problema no es abrir, es cerrar
Vale separarlo bien, porque se confunde: abrir un acceso casi siempre está justificado. Alguien tiene que mirar un log, restaurar algo, diagnosticar una caída.
Lo que falla es el otro extremo. Cerrar un acceso no tiene urgencia, no tiene dueño claro, y nadie se entera si no se hace. Es una tarea que depende enteramente de la memoria de una persona ocupada.
Cualquier proceso que dependa de eso va a fallar. No a veces: siempre, con el tiempo suficiente.
Cómo funciona el acceso con vencimiento
En ArduMaker, cuando pedís acceso SSH a un VPS, el puerto no se abre "hasta que lo cierres". Se abre con una marca de tiempo de cierre.
Un proceso de control revisa periódicamente esas marcas. Cuando una vence, cierra el puerto. Sin intervención, sin recordatorio, sin depender de que alguien esté disponible.
Desde el lado de quien lo usa no cambia nada: es SSH normal, con tu cliente de siempre y tu clave. La diferencia es lo que pasa cuando dejás de usarlo.
El efecto secundario que no esperábamos
Cuando empezamos a usarlo internamente apareció algo que no habíamos previsto, y terminó siendo lo más valioso.
Pedir acceso dejó de ser una decisión pesada.
Antes, abrir un acceso arrastraba una consecuencia indefinida, así que la gente pedía "todo, por las dudas", para no tener que volver a pedir. Cuando el acceso se revierte solo, pedir es barato. Y como es barato, la gente pide exactamente lo que necesita, por el tiempo que lo necesita.
Es el mismo fenómeno que con los backups: cuando restaurar es fácil, la gente prueba las restauraciones. Cuando es un operativo, no las prueba nunca.
Lo que queda registrado
Cada apertura queda con quién la pidió, cuándo, sobre qué VPS y hasta cuándo. Cada comando ejecutado desde la plataforma también.
Eso responde la pregunta que aparece siempre después de un incidente, que no es "¿quién tuvo la culpa?" sino "¿qué se tocó y cuándo?". Sin registro, la respuesta se reconstruye de memoria y a medias.
Si querés algo parecido sin nuestra plataforma
La idea se puede aplicar en cualquier servidor, y vale la pena aunque sea a mano:
- Una tarea programada que cierre el puerto a una hora fija, en vez de dejarlo abierto.
- Claves SSH con fecha de expiración: los certificados de SSH permiten emitir credenciales que caducan solas.
- Y lo más simple de todo: revisar una vez por mes qué está abierto. Casi siempre hay una sorpresa.
Lo importante no es la herramienta. Es mover el cierre desde "alguien se tiene que acordar" hacia "pasa solo".