Como dar acceso SSH a clientes sin exponer tu servidor

Si un cliente necesita acceso SSH, el objetivo no es abrir el puerto 22 y cruzar los dedos. El objetivo es dar el minimo acceso necesario, mantener logs claros y asegurarte de que una credencial o un error no exponga el resto de la infraestructura.

Esto importa aun mas si el servidor ejecuta automatizaciones, colas, dashboards internos o pipelines de datos publicos. SSH es acceso operativo, no una comodidad. Necesita limites, propiedad clara y plan de recuperacion.

Como se ve un modelo seguro de acceso

El patron mas limpio suele ser usuarios separados, claves SSH, rutas restringidas y un punto de entrada controlado. En muchos casos una VPN o un bastion es mejor que exponer el host directamente a internet.

• un usuario por cliente u operador, nunca root compartido
• claves SSH en lugar de contrasenas
• sudo limitado solo cuando se justifica
• logs de autenticacion y acciones administrativas
• restricciones de red antes que permisos a nivel aplicacion
• revocacion rapida cuando el acceso debe terminar

Si el mismo servidor ya soporta workers delicados o servicios para clientes, el modelo operativo debe ser tan serio como la arquitectura detras de sistemas centralizados o los flujos expuestos desde servicios tecnicos.

Patrones mas seguros que SSH publico directo

El SSH publico directo a veces es aceptable, pero no deberia ser tu opcion por defecto. Los patrones mas seguros reducen superficie expuesta antes de que la conexion llegue al host.

cliente
  - VPN o Tailscale
  - identidad por usuario

entrada
  - bastion
  - politica de IPs permitidas

servidor destino
  - claves SSH por usuario
  - sudo limitado
  - logs de auditoria

La idea no es paranoia. La idea es que el acceso sea entendible y revocable. Cuando un cliente sale, rota un proveedor o pasa un incidente, tienes que saber que desactivar y que mas queda afectado.

Hardening basico que ya deberia existir

Antes de entregar cualquier acceso, el host deberia aplicar reglas SSH predecibles.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers client_a ops_admin
MaxAuthTries 3
X11Forwarding no

Eso es solo la base. Segun el caso, tambien puede convenir comandos forzados, usuarios solo SFTP, rutas aisladas, allowlists por IP o un jump box. La opcion correcta depende de lo que el cliente realmente necesite hacer.

Errores comunes

El primer error es dar a todos el mismo usuario compartido. Eso destruye trazabilidad y hace dolorosa la revocacion.

El segundo error es dejar autenticacion por contrasena porque parece mas facil para el cliente. Mas facil hoy casi siempre significa mas ruido y mas riesgo despues.

El tercer error es mezclar acceso de cliente con tus propias rutas de administracion. Si un cliente puede ver proyectos ajenos, scripts internos o credenciales, el limite nunca fue real.

El cuarto error es olvidar restricciones a nivel de comando. Algunos clientes solo necesitan logs, hooks de despliegue o transferencia de archivos. El shell completo muchas veces sobra.

El quinto error es ignorar la trazabilidad. Si no puedes responder quien entro, cuando, desde donde y con que rol, la instalacion no esta madura.

Checklist practico antes de dar acceso

• crea un usuario SSH por persona real
• desactiva passwords y root login
• guarda claves publicas con etiqueta de propietario
• decide si hace falta VPN o bastion
• limita sudo a los comandos estrictamente necesarios
• separa datos de cliente y rutas de otros proyectos
• captura logs de auth y define retencion
• documenta como revocar antes del primer login
• revisa si el servidor tambien maneja datos internos o publicos sensibles
• prueba el acceso con una cuenta no admin primero

Cumplimiento, trazabilidad y estabilidad

Si el host toca registros de cliente, dashboards internos, backups o flujos de recogida de datos publicos, el control de acceso forma parte del cumplimiento, no es un detalle lateral. Un cliente solo deberia alcanzar lo que permiten el contrato y el modelo operativo.

{
  "user": "client_a",
  "allowed_role": "log-review",
  "entry_path": "vpn+bastion",
  "sudo": false,
  "revoked_on_exit": true
}

Ese tipo de politica ayuda en auditorias, handoffs e incidentes. Estabilidad no es solo uptime. Tambien es tener un modelo de acceso que puedes explicar sin improvisar.

Cuando tiene sentido contratar a alguien tecnico

Si el acceso de clientes ya esta mezclado con scripts de despliegue, usuarios compartidos, reglas de firewall improvisadas y excepciones sin documentar, el sistema necesita limpieza antes que otra cuenta mas. Eso es trabajo de arquitectura.

Ahi es donde ayuda directa desde fractional CTO o trabajo de infraestructura desde servicios puede ahorrar mucho tiempo. El valor no es solo endurecer SSH. Es disenar un modelo operativo estable alrededor de permisos, logs y aislamiento.

Conclusion

Dar acceso SSH a clientes no es intrinsecamente peligroso. Dar acceso amplio, mal documentado y dificil de revocar si lo es. Un buen diseno de SSH usa minimo privilegio, limites claros de identidad y trazas de auditoria faciles de revisar.

Si necesitas revisar un modelo de acceso para clientes, separar entornos o salir del habito de root compartido, usa contacto y trae el layout actual del servidor, las necesidades reales de acceso y los limites de cumplimiento.