Deploy keys, SSH y tokens en GitHub: qué credencial usar para desplegar
Publicado el 2026-10-26 por frfrand
Acceso seguro de servidores a repositorios GitHub sin compartir cuentas
Para que un VPS descargue un repositorio privado no deberías copiar tu contraseña personal al servidor. GitHub ofrece mecanismos diferentes de acceso: una deploy key, un token o una GitHub App. La mejor opción depende del alcance y la automatización.
La idea es usarlo para resolver un problema de verdad, no memorizar comandos porque quedan bien en una captura. Vamos con lo esencial, un ejemplo de trabajo y los errores que más conviene evitar.
Qué hace Deploy keys, SSH y tokens y cuándo sirve
Una deploy key SSH suele asociarse a un repositorio concreto y puede configurarse de sólo lectura. Los tokens personales tienen permisos y vencimientos configurables, pero conviene evitar scopes innecesarios. Las GitHub Apps pueden emitir credenciales de corta duración y granularidad más adecuada a integraciones grandes.
Si estás aprendiendo, probalo primero en un repositorio o entorno de prueba. Si administrás producción, documentá el estado antes de ejecutar nada que altere archivos, historial o datos. Eso te permite entender qué cambió y recuperarte si te equivocás.
Ejemplo para copiar y entender
# En el VPS, crear una clave específica de despliegue
ssh-keygen -t ed25519 -f ~/.ssh/deploy_proyecto -C 'deploy-proyecto'
# Ver sólo la CLAVE PUBLICA
cat ~/.ssh/deploy_proyecto.pub
# Verificar GitHub al conectar
ssh -T git@github.comNo copies la orden final sin mirar el estado previo. Los nombres de ramas, host, usuario o rutas son ejemplos; reemplazalos por los de tu proyecto. Algunos comandos modifican archivos o hacen peticiones que pueden escribir datos.
Cómo lo usaría paso a paso
- Paso 1. Creá una identidad separada para el despliegue, no reutilices la clave SSH personal.
- Paso 2. Añadí únicamente la clave pública al repositorio como deploy key de lectura, cuando el flujo lo permita.
- Paso 3. Verificá la huella del host de GitHub con información oficial antes de aceptar el primer acceso.
- Paso 4. Guardá la privada con permisos estrictos y no la copies dentro de Git.
- Paso 5. Documentá cómo revocar el acceso cuando cambie el equipo o el servidor.
Detenete después de cada paso y comprobá el resultado. Si algo falla, anotá el mensaje exacto antes de cambiar de estrategia. Saltar entre cinco soluciones aleatorias suele dificultar encontrar la causa real.
Un caso que podría pasarte trabajando con clientes
Una agencia administra repositorios privados de distintos clientes. Con credenciales separadas por proyecto, un servidor comprometido no necesita tener lectura sobre todos los repositorios de la agencia.
El objetivo no es que «funcione una vez», sino que puedas explicar cómo lo repetís sin comprometer otra aplicación. Si hay datos o credenciales de clientes, trabajá con pruebas separadas y accesos mínimos.
El error que más veo
Nunca pegues una clave privada en una incidencia ni la pases a una IA o colaborador sin controles. Las credenciales también pueden quedar expuestas en logs de CI; evitá comandos que impriman secretos.
Una regla sencilla: si no podés explicar qué hará el comando sobre tu código o servidor, mirá primero su ayuda oficial. Así evitás confundir una solución rápida con un problema nuevo.
¿Dónde entra ArduMaker?
En ArduMaker, las integraciones Git del despliegue deben usar permisos mínimos por proyecto y Empresa. Elegí claves separadas para evitar que el VPS de un cliente acceda al código de otro.
Por ejemplo, podés desplegar desde un repositorio Git a un VPS, asociar un dominio HTTPS y administrar servicios y bases desde el mismo entorno. El panel reduce tareas repetitivas de infraestructura, pero no reemplaza Git, las pruebas ni la revisión de permisos del proyecto.
Preguntas rápidas antes de aplicarlo
¿Esto cambia producción? Depende de dónde ejecutes la acción. Probá localmente primero, identificá el commit o servicio afectado y prepará un plan de recuperación.
¿Cómo compruebo que salió bien? No te quedes con la ausencia de mensajes de error: revisá el estado, ejecutá un test funcional y comprobá los logs o el historial correspondiente.
¿Conviene automatizarlo? Si es repetible y tiene resultados verificables, sí. Pero la automatización debería fallar de forma clara y no esconder errores o credenciales.
Para ampliar
Resumen: la herramienta útil no es la que tiene más opciones, sino la que te permite entender qué cambió, comprobarlo y seguir trabajando sin sorpresas.