Cómo dar acceso a tu equipo sin repartir contraseñas
Publicado el 2026-09-12 por frfrand
Por qué la contraseña compartida siempre termina filtrada, cómo se reparte el acceso por persona y por proyecto, y qué tiene que pasar el día que alguien se va del equipo.
Empieza siempre igual y siempre con buena intención. Hay que entregar algo, entra alguien nuevo, y la forma rápida es pasarle la contraseña que ya existe.
El problema no es esa decisión. Es que no tiene marcha atrás.
Seis meses después, esa contraseña vive en tres chats distintos, la conocen personas que ya no trabajan en el proyecto, y cambiarla implica coordinar con siete personas a la vez. Así que no se cambia.
Por qué la credencial compartida es un problema estructural
No es una cuestión de cuidado. Son cuatro propiedades que tiene por diseño.
No se puede revocar parcialmente. Si querés sacarle el acceso a una persona, tenés que cambiar la credencial para todos. Como eso molesta a todos, se pospone indefinidamente.
No identifica. El log dice que "el usuario admin reinició el servicio". No sirve para entender qué pasó, y tampoco para pedir ayuda: no sabés a quién preguntarle.
No se puede graduar. Una contraseña da todo o nada. No existe "puede ver los logs pero no reiniciar", que suele ser exactamente lo que hace falta.
Se copia sin dejar rastro. Una credencial que pasó por un chat está en el historial de ese chat, en su backup, y en cualquier máquina donde alguien la haya pegado en un archivo temporal.
El modelo que funciona: una identidad por persona
La alternativa no es complicada de describir:
- Cada persona entra con su propia cuenta.
- Cada persona tiene su propia clave SSH, y el servidor guarda las claves públicas de todas.
- Los permisos se otorgan a la persona, no a una credencial que circula.
El cambio importante no está en cómo se da el acceso, sino en cómo se saca. Quitar a una persona pasa de ser "coordinar un cambio de contraseña con todo el equipo" a "borrar una línea".
Sobre las claves SSH vale aclarar un punto que confunde a mucha gente: no hay ningún problema en que el servidor tenga las claves públicas de diez personas en ~/.ssh/authorized_keys. La clave pública no permite deducir la privada. Sacar a alguien es borrar su línea de ese archivo, y no afecta a nadie más.
Tres preguntas antes de dar un acceso
Vale la pena hacérselas una vez, al principio. Ahorran mucha limpieza después.
¿Quién es esta persona? Su propia cuenta, siempre. Aunque sea por dos semanas. Aunque sea el fundador.
¿Qué necesita tocar? Casi nunca es "todo". Un freelancer que trabaja para un cliente necesita ver ese cliente. Un diseñador necesita subir archivos, no reiniciar servicios.
¿Por cuánto tiempo? Un contratista no es un miembro permanente. Si el acceso tiene fecha de fin, ponérsela desde el día uno es gratis; acordarse dentro de tres meses, no.
La regla por defecto: dar el alcance más chico que permita hacer el trabajo. Ampliarlo después es un clic; darse cuenta de que era demasiado, no.
Cómo lo resolvimos en ArduMaker
La estructura de la plataforma está armada alrededor de esto.
Las Empresas separan clientes. Cada cliente vive en su propia Empresa, con sus VPS, sus dominios, su facturación y su equipo. Alguien que pertenece a una Empresa no ve las otras. No es una cuestión de permisos bien configurados: no hay un lugar donde se toquen.
Los roles separan responsabilidades. Un Miembro trabaja; sólo un Admin toca medios de pago y facturación. El desarrollador que despliega no necesita, ni ve, la tarjeta del cliente.
Las claves SSH son por persona. Cada usuario del VPS tiene la suya, se cargan desde el panel, y se quitan de a una.
Todo queda registrado. Cada comando ejecutado sobre un VPS desde la plataforma guarda quién lo lanzó y cuándo.
El día que alguien se va
Esta es la prueba real del modelo. Si la lista lleva más de cinco minutos, algo estaba mal armado antes.
- Quitar la membresía. Una acción, en un solo lugar.
- Dar de baja su clave SSH. Trivial si las claves eran por persona.
- Rotar lo que esa persona sabía de memoria. Idealmente, poco: tokens de API que haya usado, y credenciales de servicios externos.
- Mirar el registro. Qué tocó en las últimas semanas. No por desconfianza: porque si dejó algo a medias, es mejor enterarse ahora.
La idea corta
Repartir acceso es fácil. Lo difícil, y lo que define si tu equipo tiene un problema de seguridad o no, es poder retirarlo rápido y sin romperle el trabajo a nadie más.
Si hoy te tocara sacar a una persona de tu producción, ¿cuánto tardarías? Esa respuesta dice más sobre tu infraestructura que cualquier checklist.
