Alguien tiene que entrar en un servidor esta noche y la credencial tiene que llegarle ya. La tentación es pegar la clave privada o la contraseña de root en Slack. Cada mensaje por el que pasa esa clave guarda una copia, y por eso la mejor vía es un enlace de un solo uso que expira: el secreto se recupera una vez y después desaparece.
Aun así, el enlace es solo el paso de entrega. Antes de crearlo, elige la credencial adecuada, limítala a la tarea y decide cómo vas a quitarla. Esta guía cubre todo eso, incluida la cuestión de qué poner en un enlace de un solo uso para compartir los datos de acceso a un servidor y qué dejar fuera.
¿Qué credencial SSH estás compartiendo realmente?
El acceso SSH puede basarse en cuatro cosas distintas, y cada una tiene reglas muy diferentes para compartirse.
| Credencial | Qué es | ¿Debería moverse alguna vez? |
|---|---|---|
| Clave pública | La mitad que guarda el servidor | Sí, sin problema. No es secreta. |
| Clave privada | La mitad que tiene el usuario | Solo si se genera para el destinatario, y solo una vez |
| Contraseña | Una cadena compartida que comprueba el servidor | Una vez, como valor temporal que vas a cambiar |
| Certificado SSH | Una clave firmada por tu CA con un periodo de validez | El certificado no es secreto; la clave que hay detrás, sí |
La mejor entrega es aquella en la que no se mueve nada secreto. Si
el destinatario ya tiene un par de claves SSH, pídele la clave pública,
añádela a ~/.ssh/authorized_keys en la cuenta correcta y dile que se
conecte. Para quitarle el acceso más adelante basta con borrar esa línea.
Genera una clave exclusiva para esa persona cuando no tenga una y no pueda crearla. No envíes nunca tu clave privada de uso diario. Una clave creada para el destinatario se puede limitar, registrar y eliminar sin tocar nada más.
Para necesidades recurrentes, prefiere certificados o acceso gestionado. Si la misma persona va a necesitar acceso una y otra vez, repetir entregas de un solo uso no es la herramienta adecuada. Un certificado SSH de validez corta, o una herramienta de acceso como Teleport o Tailscale SSH, te da una expiración integrada en la propia credencial, en lugar de añadida a la entrega.
Limita la credencial antes de compartirla
Envíes lo que envíes, que sea lo más reducido que permita la tarea:
- Una cuenta, un host. Añade la clave a la cuenta de servicio responsable del trabajo, no a root, y solo en la máquina implicada.
- Restringe lo que puede hacer la clave con opciones de
authorized_keyscomofrom="203.0.113.5",no-port-forwardingo un envoltoriocommand=cuando la tarea sea un único script. - Dale fecha de expiración a la contraseña. Si compartes una
contraseña, usa
passwd -eo el equivalente de la plataforma para que el destinatario tenga que cambiarla en su primer inicio de sesión, y prevé desactivar la cuenta en una fecha concreta. - Apunta la fecha de fin antes de enviar nada. «Cuando termine el trabajo» no es una fecha.
Cómo compartir credenciales SSH con un enlace que expira
- Confirma el destinatario por un canal en el que ya confíes: el ticket, un hilo de correo conocido o una llamada. La mayoría de las credenciales que llegan a quien no debían se deben a una dirección parecida o a un nombre autocompletado.
- Pega solo el secreto en la herramienta de enlaces secretos de un solo uso. Para una clave privada, eso significa el bloque PEM completo y nada más. Con LinkPilot, el texto se cifra en tu navegador antes de almacenarse, así que el servicio solo guarda texto cifrado, y la clave para descifrarlo está en la parte de la URL que los navegadores no envían a los servidores.
- Ajusta la expiración al plazo real. Una hora si está esperándolo, 24 horas si está en otra zona horaria, siete días solo cuando haya un motivo real. El enlace también se destruye la primera vez que se abre, así que la expiración es la red de seguridad, no el control principal.
- Añade una frase de contraseña con una cuenta Pro cuando la credencial sea sensible, y transmítela por otro canal. En el plan Pro, el historial de auditoría también te muestra cuándo se mostró el secreto.
- Envía el enlace con una línea que explique para qué es y sin datos de conexión.
- Envía los datos de conexión en otro mensaje: host o dirección, puerto, nombre de usuario y método de autenticación. Ninguno es secreto por sí solo, pero junto con la clave forman el acceso completo.
Si el enlace indica que ya se ha abierto y el destinatario dice que no lo abrió, no lo discutas. Da la credencial por expuesta, quita la clave o cambia la contraseña y genera una nueva.
Un enlace de un solo uso para compartir los datos de acceso a un servidor
La duda sobre qué va dentro del secreto aparece siempre. Una buena regla es que el enlace lleve lo que un atacante no podría adivinar, y el mensaje normal, lo que sí podría.
En el enlace de un solo uso:
- La clave privada o la contraseña temporal
- La frase de contraseña de la clave, si se puso una al generarla
- Nada más
En un mensaje normal, enviado aparte:
- Nombre de host o dirección IP, y puerto
- La cuenta con la que iniciar sesión
- Si hay que usar clave o contraseña
- La huella de la clave del host, para que el destinatario pueda verificar el servidor en la primera conexión
- Una nota breve sobre para qué es el acceso y cuándo termina
Deja las capturas de pantalla y los registros de terminal fuera de los dos. Una captura de una sesión en marcha suele incluir tokens, direcciones internas y otros nombres de usuario que nunca debían salir de ahí.
Ayuda al destinatario a guardar la clave de forma segura
Una entrega segura sigue fallando si la clave acaba en Descargas con permisos de lectura para todo el mundo. Envía estas instrucciones junto con los datos de conexión:
# save the key, then lock it down
chmod 600 ~/.ssh/acme_deploy
ssh-add ~/.ssh/acme_deploy
# verify the host key fingerprint against the one you were sent
ssh -i ~/.ssh/acme_deploy deploy@203.0.113.5
Pídele que abra el enlace secreto solo cuando esté listo para usarlo, en un dispositivo que controle y con una conexión de confianza. Abrirlo en una máquina compartida «para ver si funciona» deja una copia en el historial del portapapeles de esa máquina.
Verifica y cierra la ventana de acceso
Mientras la ventana de acceso siga abierta, pide al destinatario que pruebe la conexión exacta que va a usar y confirme que la tarea funciona. No amplíes los permisos para que pase una prueba; corrige el alcance.
Cuando termine el trabajo:
- Quita la clave pública de
authorized_keys, desactiva la cuenta o deja que el certificado expire según lo previsto. - Cambia todo lo que viajó junto con la credencial, incluida una contraseña temporal que debía cambiarse en el primer inicio de sesión y no se cambió.
- Revisa
auth.logo tu fuente de auditoría de SSH en busca de conexiones fuera del horario acordado o desde direcciones inesperadas. - Anota quién tuvo qué, desde cuándo y hasta cuándo. El registro se queda; la credencial, no.
La expiración del enlace limita durante cuánto tiempo se podía recuperar el secreto. La expiración de la credencial limita durante cuánto tiempo se puede usar. Necesitas las dos, y la segunda es la que la gente olvida.