Una clave SSH por persona: el detalle que cambia todo cuando sos equipo
Publicado el 2026-09-12 por frfrand
Por qué compartir una clave privada arruina el modelo entero, cómo se agregan y quitan claves sin tocar a nadie más, y qué hacer el día que alguien pierde la laptop.
Hay un atajo muy común en equipos chicos: se genera una clave SSH "del proyecto", se guarda en el gestor de contraseñas compartido, y todo el mundo la usa.
Funciona. Y desarma casi todo lo bueno que tiene SSH.
Por qué la clave compartida rompe el modelo
El diseño de SSH se apoya en una premisa: la clave privada identifica a alguien y no sale de su máquina. Si la clave circula, esa premisa desaparece y con ella tres propiedades:
Ya no identifica. El log dice que entró "deploy". No sabés quién. Después de un incidente, la pregunta "¿quién ejecutó esto?" no tiene respuesta.
Ya no se puede revocar de a uno. Sacarle el acceso a una persona implica generar una clave nueva y distribuirla a todos los demás. Como eso molesta a todo el mundo, se pospone. Y así es como una persona que se fue hace ocho meses sigue pudiendo entrar.
No sabés cuántas copias hay. Una clave privada que pasó por un gestor compartido está en cada laptop donde alguien la descargó, y en cualquier backup de esas laptops.
Lo que mucha gente no sabe
La razón por la que se comparte suele ser una idea equivocada: que poner varias claves es complicado, o que tener muchas claves públicas en un servidor lo debilita.
Ninguna de las dos es cierta.
El archivo ~/.ssh/authorized_keys es una lista. Una clave pública por línea. Podés tener veinte y no pasa nada, porque una clave pública no permite deducir la privada. Ese es el punto entero del cifrado asimétrico.
# ~/.ssh/authorized_keys ssh-ed25519 AAAAC3Nza... ana@laptop ssh-ed25519 AAAAC3Nza... bruno@laptop ssh-ed25519 AAAAC3Nza... ci-deploy
El comentario final de cada línea (ana@laptop) no tiene función técnica y es justamente lo que lo hace mantenible: es lo que te permite saber, dentro de seis meses, de quién es cada una.
Cómo se agrega y se quita
Agregar, desde la máquina de la persona:
ssh-copy-id ana@miservidor.com
Quitar: borrar su línea del archivo. Eso es todo. Nadie más se entera, nadie más tiene que cambiar nada.
Compará eso con el otro modelo, donde sacar a alguien implica coordinar un cambio con todo el equipo. La diferencia no está en cómo se da el acceso: está en cuánto cuesta retirarlo.
Las claves de las máquinas también son personas
Un servidor de integración continua que despliega necesita su propia clave, distinta de las de las personas. Dos razones:
- Si el sistema de CI se compromete, revocás esa clave sin tocar a nadie.
- Esa clave puede tener permisos más chicos. Con la opción command en authorized_keys se puede forzar que esa clave sólo ejecute un script determinado, sin shell interactiva:
command="/usr/local/bin/deploy.sh",no-pty ssh-ed25519 AAAA...
Es de las funciones más útiles y menos usadas de SSH.
El día que alguien pierde la laptop
Con claves por persona, el procedimiento es corto: borrar esa línea en los servidores donde estaba, y generar un par nuevo.
Con clave compartida, el procedimiento es rotar la clave del proyecto entero y coordinar con todos. Que es exactamente por lo que, en la práctica, no se hace.
Una recomendación que ahorra ese susto: poné passphrase a la clave privada. Si alguien te roba la máquina, el archivo solo no le alcanza. El agente de SSH la guarda mientras dura tu sesión, así que no tenés que escribirla todo el tiempo.
Cómo lo hacemos nosotros
En ArduMaker cada usuario de un VPS tiene su propia clave, cargada desde el panel. Agregar a alguien es sumar su clave pública; sacarlo es quitarla. No hay una credencial compartida que rotar, y cada comando ejecutado desde la plataforma queda asociado a quién lo lanzó.
Es la misma idea de siempre: lo que define un buen modelo de acceso no es lo fácil que sea dar permiso, sino lo rápido que se pueda sacar.