WardtermCliente SSH
ES
Descargar

Cómo compartir acceso SSH sin compartir tu clave privada

Pide a cada persona su clave pública y añádela al servidor: en su propia cuenta o como una línea aparte en el ~/.ssh/authorized_keys de la cuenta compartida. Tu clave privada se queda en tu dispositivo, los registros muestran qué clave se usó y quitar a una persona es borrar una línea. Para un acceso temporal, añade expiry-time= a la línea o firma un certificado SSH de corta duración.

Actualizada el . Ejecutado con OpenSSH 10.0 en Debian 13 en un contenedor desechable: cuentas por persona creadas con install, una cuenta compartida con una línea por persona y expiry-time (una línea caducada fue rechazada), un certificado de usuario firmado con -V +8h y aceptado mediante TrustedUserCAKeys, borrar una línea, usermod --expiredate y pkill.

Por qué no compartir la clave sin más

Enviar tu clave privada a un compañero, o una copia de una clave de despliegue que usan todos, funciona el primer día y da problemas después:

  • El servidor ve una sola clave, así que sus registros no pueden decir quién hizo qué.
  • Cuando alguien se va, la única forma de quitarle el acceso es una clave nueva para todos.
  • Cada copia en un portátil, en el historial de un chat o en una copia de seguridad es un sitio más por donde puede filtrarse.

SSH está pensado para lo contrario: cada persona tiene su propio par de claves, guarda la parte privada y solo reparte la pública. Un servidor puede confiar en tantas claves públicas como quieras.

Una cuenta por persona

Lo más limpio es dar a cada persona su propia cuenta de Linux. Pide su clave pública y luego, en el servidor:

sudo adduser --disabled-password --gecos "" bob
sudo install -d -m 700 -o bob -g bob /home/bob/.ssh
sudo install -m 600 -o bob -g bob bob.pub /home/bob/.ssh/authorized_keys

En RHEL y sistemas parecidos, usa sudo useradd -m bob para la primera línea. Añade la cuenta al grupo sudo o wheel solo si necesita root, como se explica en crear un usuario con acceso SSH y sudo. Así cada comando queda ligado a un nombre y los archivos conservan su propietario.

Varias personas en una cuenta compartida

A veces todos tienen que entrar con el mismo usuario, como deploy o el usuario por defecto de una imagen en la nube. En ese caso, da a cada persona su propia línea en el authorized_keys de esa cuenta, con un comentario que la identifique:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGk3... alice@laptop
expiry-time="20261231" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJq8... bob@laptop

La opción expiry-time hace que la línea de Bob deje de funcionar después de esa fecha, sin tener que acordarte de nada. Otras opciones limitan una clave a ciertas direcciones o a un solo comando, consulta restringir una clave SSH. Como cada persona tiene una clave distinta, el registro del servidor las sigue distinguiendo por huella:

Accepted publickey for deploy from 203.0.113.25 port 51234 ssh2: ED25519 SHA256:vsze5ORPbYF/MMM4TTtuyy6yiEAYV1CcI4FOF0dV9wI

Lista las huellas del archivo para saber de quién es esa clave:

ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Acceso de corta duración con certificados

Con muchos servidores y cambios frecuentes, editar authorized_keys en todas partes acaba cansando. Una autoridad de certificación SSH lo resuelve: los servidores confían en la CA una vez y tú firmas la clave pública de cada persona por un tiempo determinado.

ssh-keygen -t ed25519 -f user_ca -C "team user CA"
ssh-keygen -s user_ca -I bob@example.com -n deploy -V +8h bob.pub

Esto crea bob-cert.pub, válido durante ocho horas como el usuario deploy. En cada servidor, copia user_ca.pub a /etc/ssh/user_ca.pub y añade una línea a sshd_config:

TrustedUserCAKeys /etc/ssh/user_ca.pub

Bob guarda bob-cert.pub junto a su clave privada y entra como siempre. Cuando caduca, el acceso termina sin tocar ningún servidor. Guarda la clave de la CA sin conexión o en un sistema dedicado, porque puede firmar acceso a todo. La configuración completa está en los certificados SSH explicados.

Quitar el acceso

Para una línea de clave, bórrala. Borrar por comentario es rápido; para una limpieza a fondo, busca por huella, como se muestra en revocar una clave SSH cuando alguien se va:

sudo sed -i.bak '/ bob@laptop$/d' /home/deploy/.ssh/authorized_keys

Para una cuenta personal, bloquéala para que no funcionen ni la clave ni la contraseña, y termina lo que siga en marcha:

sudo usermod --expiredate 1 bob
sudo pkill -KILL -u bob

Quitar una clave no cierra las sesiones ya abiertas, así que no te saltes el segundo comando. Después cambia cualquier contraseña, token o clave compartida que la persona conociera.

Enseñar tu terminal en directo

A veces lo que hace falta no es acceso sino ayuda: alguien tiene que ver cómo trabajas, o escribir un minuto. En un servidor donde los dos tenéis cuenta, tmux puede compartir una sesión. Crea un grupo para ello y arranca tmux en un socket al que ese grupo pueda llegar:

sudo groupadd pair
sudo usermod -aG pair alice
sudo usermod -aG pair bob
tmux -S /tmp/pair new -s pair

Desde otra ventana, abre el socket al grupo y deja entrar a Bob. tmux 3.3 y posteriores rechazan a otros usuarios hasta que lo hagas:

chgrp pair /tmp/pair
chmod 770 /tmp/pair
tmux -S /tmp/pair server-access -a bob
tmux -S /tmp/pair server-access -r bob

La última línea deja a Bob en solo lectura; quítala para que pueda escribir. Él se une con tmux -S /tmp/pair attach -t pair. Cuando terminéis, tmux -S /tmp/pair server-access -d bob lo saca. Los dos necesitáis una cuenta en ese servidor, y todo lo que Bob escribe se ejecuta como tú.

Contraseñas compartidas y otros secretos

Hay cosas que no se pueden repartir por persona: un equipo de red con una sola contraseña de administrador, la contraseña root de una base de datos, una clave de despliegue de un repositorio. Guárdalas en un gestor de contraseñas o una bóveda que comparta el equipo, no en un chat ni en una página de wiki, para saber quién puede leerlas. Cuando alguien se va, cambia cada secreto que podía ver, porque quitarle el acceso a la bóveda no borra lo que ya copió.

Preguntas

¿Pueden dos personas usar la misma clave privada SSH?

Técnicamente sí, pero entonces el servidor no puede distinguirlas, y quitarle el acceso a una obliga a cambiar la clave para todos. Mejor que cada persona tenga su propia clave.

¿Es seguro enviar una clave pública por correo o chat?

Sí. Una clave pública está hecha para compartirse. Solo la clave privada, el archivo sin .pub, debe quedarse en el dispositivo de su dueño.

¿Cómo doy acceso a alguien solo durante unos días?

Pon expiry-time="20261231" delante de su clave en authorized_keys, o firma su clave como certificado con ssh-keygen -s y una validez como -V +3d. Ambos dejan de funcionar solos.

¿Puedo dejar que alguien vea mi terminal sin darle acceso?

Sí. Con tmux, un socket compartido y server-access -r, puede mirar en modo solo lectura. Aun así necesita una cuenta en el mismo servidor para unirse.

Fuentes

Más en Proteger un servidor

Todas las guías