Abrir un ticket
leafleafFlower illustration
Updated on 1 de junio de 2026
Guía de Git

Cómo configurar el acceso SSH a repositorios Git privados desde cPanel

Para clonar y trabajar con repositorios Git privados desde un servidor con cPanel, la forma más segura es mediante autenticación SSH con clave pública. A diferencia de las credenciales de usuario y contraseña, las claves SSH permiten autenticación sin contraseña de forma segura y son el método estándar para despliegues automatizados.

Esta guía cubre el proceso completo: generar la clave en el servidor, registrarla en el proveedor y configurar SSH para múltiples repositorios. Aplica a GitHub, GitLab y Bitbucket. Si no estás familiarizado con los comandos básicos, revisa primero la guía de comandos Git más usados.

Requisitos previos

  • Cuenta de cPanel con acceso SSH y Terminal habilitados.
  • Acceso al servidor por SSH externo o mediante cPanel → Avanzado → Terminal.
  • Permisos para añadir deploy keys al repositorio privado en el proveedor.

⚠️ En los ejemplos se usa GitHub, pero el procedimiento es prácticamente idéntico para GitLab y Bitbucket. Las diferencias se indican en cada paso.

Paso 1 — Conectarse por SSH o abrir el Terminal de cPanel

Todos los comandos se ejecutan en el servidor, no en tu equipo local:

  • SSH externo: ssh usuario@tudominio.com desde tu terminal local.
  • Terminal de cPanel: Avanzado → Terminal. Es la opción más sencilla si no tienes cliente SSH configurado.

Paso 2 — Generar una clave SSH para el repositorio

Genera una clave SSH dedicada. Tener claves separadas por repositorio facilita la revocación en caso de incidente sin afectar a otros repositorios.

Opción A — Ed25519 (recomendada)

ssh-keygen -t ed25519 -f ~/.ssh/NOMBRE_CLAVE -C "USUARIOCP@DOMINIOCP"

Ed25519 es más moderna, más segura y genera claves más cortas que RSA. Compatible con GitHub, GitLab y Bitbucket actuales.

Opción B — RSA 4096 (máxima compatibilidad)

ssh-keygen -t rsa -b 4096 -f ~/.ssh/NOMBRE_CLAVE -C "USUARIOCP@DOMINIOCP"

Usa RSA solo si necesitas compatibilidad con servidores Git propios muy antiguos (OpenSSH < 6.5).

Sustituye NOMBRE_CLAVE por un nombre descriptivo (por ejemplo mi-proyecto), USUARIOCP por tu usuario de cPanel y DOMINIOCP por tu dominio principal. Ejemplo completo:

ssh-keygen -t ed25519 -f ~/.ssh/mi-proyecto -C "usuariocp@midominio.com"

Cuando pregunte por passphrase, déjala vacía (pulsa Enter dos veces). Los despliegues automatizados no pueden introducir passphrase de forma interactiva.

Se generan dos archivos: ~/.ssh/mi-proyecto (clave privada — nunca la compartas) y ~/.ssh/mi-proyecto.pub (clave pública — esta es la que registrarás en el proveedor).

Paso 3 — Crear y configurar ~/.ssh/config

El archivo ~/.ssh/config indica a SSH qué clave usar para cada host. Sin él, SSH intentará la clave por defecto y fallará.

touch ~/.ssh/config
chmod 0600 ~/.ssh/config
chown USUARIOCP:USUARIOCP ~/.ssh/config

Abre el archivo:

nano ~/.ssh/config

Añade la entrada para tu proveedor:

Host github.com
    IdentityFile ~/.ssh/mi-proyecto

Guarda con Ctrl+X → Y → Enter.

IdentityFile apunta al archivo privado (sin extensión .pub). Si gestionas varios repositorios con claves distintas, consulta el Paso 6 para usar alias.

Paso 4 — Registrar la clave pública en el proveedor

Muestra tu clave pública y cópiala completa:

cat ~/.ssh/mi-proyecto.pub

Copia toda la línea (empieza por ssh-ed25519 o ssh-rsa y termina con el comentario).

En GitHub

  1. Abre el repositorio privado → Settings → Deploy keys → Add deploy key.
  2. Título descriptivo (por ejemplo cPanel producción) y pega la clave pública en Key.
  3. Marca Allow write access solo si el servidor necesita hacer push. Para despliegues de solo lectura, déjalo sin marcar.
  4. Guarda con Add key.

En GitLab

  1. Repositorio → Settings → Repository → Deploy keys → Add new deploy key.
  2. Nombre, pega la clave pública y selecciona si otorgas escritura. Guarda.

Alternativa: para acceso a toda tu cuenta, ve a Preferencias de usuario → Claves SSH.

En Bitbucket

  1. Repositorio → Repository settings → Access keys → Add key.
  2. Etiqueta, pega la clave pública y guarda.

Alternativa: para acceso a nivel de cuenta, ve a Personal settings → SSH keys.

Paso 5 — Verificar que la autenticación SSH funciona

Antes de clonar, comprueba que la clave está aceptada:

ssh -i ~/.ssh/mi-proyecto -T git@github.com

Para GitLab: ssh -i ~/.ssh/mi-proyecto -T git@gitlab.com
Para Bitbucket: ssh -i ~/.ssh/mi-proyecto -T git@bitbucket.org

Respuestas de éxito:

  • GitHub: Hi usuario! You've successfully authenticated, but GitHub does not provide shell access.
  • GitLab: Welcome to GitLab, @usuario!
  • Bitbucket: logged in as usuario.

Si aparece Permission denied (publickey), revisa que la clave pública esté registrada correctamente en el proveedor y que ~/.ssh/config apunte al archivo privado correcto.

Paso 6 — Múltiples repositorios con alias (opcional)

Si gestionas varios repositorios con claves distintas, define alias en ~/.ssh/config para que SSH use la clave correcta en cada caso.

Ejemplo con dos repositorios en GitHub:

Host github.com-proyecto1
    HostName github.com
    IdentityFile /home/usuariocp/.ssh/proyecto1

Host github.com-proyecto2
    HostName github.com
    IdentityFile /home/usuariocp/.ssh/proyecto2

Ejemplo con GitHub y GitLab simultáneamente:

Host github.com
    HostName github.com
    IdentityFile /home/usuariocp/.ssh/clave-github

Host gitlab.com
    HostName gitlab.com
    IdentityFile /home/usuariocp/.ssh/clave-gitlab
  • Host es el alias que usarás en las URLs SSH al clonar.
  • HostName es el dominio real del proveedor.
  • Usa rutas absolutas en IdentityFile cuando uses alias (con /home/usuariocp/).

Paso 7 — Clonar el repositorio privado

Con una sola clave para el host (sin alias)

git clone git@github.com:USUARIO_REMOTO/NOMBRE_REPO.git

Ejemplo:

git clone git@github.com:miempresa/mi-proyecto.git

Con alias definidos para múltiples claves

Sustituye el dominio del proveedor por el alias definido en Host:

git clone git@github.com-proyecto2:miempresa/proyecto2.git

Una vez clonado, los comandos habituales (git pull, git push, git fetch) funcionan sin cambios adicionales dentro del directorio del repositorio.

Permisos correctos y buenas prácticas de seguridad

SSH rechaza las claves si los permisos son demasiado abiertos. Aplica siempre:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/mi-proyecto
chmod 600 ~/.ssh/mi-proyecto.pub
chmod 600 ~/.ssh/config

Verifica con: ls -la ~/.ssh

Buenas prácticas:

  • Una clave por repositorio: facilita la revocación selectiva sin afectar a otros repos.
  • Claves de solo lectura para despliegues: no marques “Allow write access” salvo que el servidor necesite hacer push.
  • Rotación periódica: regenera las claves cada 6-12 meses o cuando personal externo haya tenido acceso al servidor.
  • Documenta qué clave está en cada repositorio y quién es responsable.
  • Nunca copies la clave privada fuera del servidor. Si necesitas acceso desde otro equipo, genera una nueva clave en ese equipo.

Errores comunes y soluciones

«Permission denied (publickey)»

La clave pública no está registrada o se copió incompleta en el proveedor. Verifica en Deploy keys del repositorio que aparece la entrada y que incluye el prefijo completo (ssh-ed25519 o ssh-rsa).

«Warning: Unprotected private key file!»

Los permisos de la clave privada son demasiado abiertos. Corrígelo con: chmod 600 ~/.ssh/mi-proyecto.

La prueba SSH funciona pero git clone falla con «Repository not found»

Dos causas: (1) el usuario remoto o el nombre del repositorio en la URL son incorrectos — cópialos desde el botón “SSH” del repositorio en la interfaz web; (2) si usas alias, la URL de clone debe usar el alias, no el dominio real.

«Host key verification failed»

El servidor no tiene la huella digital del proveedor en ~/.ssh/known_hosts. Ejecuta ssh -T git@github.com (o el proveedor correspondiente), acepta la huella cuando pregunte, y vuelve a intentarlo.

«Too many authentication failures»

SSH prueba todas las claves de ~/.ssh/ y el servidor remoto corta la conexión por exceso de intentos. Añade IdentitiesOnly yes al bloque correspondiente en ~/.ssh/config:

Host github.com
    IdentityFile ~/.ssh/mi-proyecto
    IdentitiesOnly yes

El archivo config no funciona aunque parezca correcto

SSH es sensible a la sintaxis: (1) la indentación debe ser con espacios, no tabulaciones; (2) no debe haber espacios al final de las líneas; (3) los permisos del archivo deben ser exactamente 600. Verifica con: ssh -G github.com y comprueba que identityfile apunta al archivo correcto.

Preguntas frecuentes

¿Cuál es la diferencia entre una deploy key y una clave SSH de cuenta?

Una deploy key se registra a nivel de repositorio y solo da acceso a ese repositorio. Una clave de cuenta da acceso a todos los repositorios de esa cuenta. Para hosting y despliegues, las deploy keys son más seguras porque limitan el radio de daño si la clave se compromete.

¿Ed25519 o RSA 4096?

Ed25519 si tu proveedor lo soporta (GitHub, GitLab y Bitbucket lo soportan todos en sus versiones actuales). Es más moderno y más seguro. RSA 4096 sigue siendo seguro y es la opción para servidores Git propios muy antiguos (OpenSSH < 6.5).

¿La passphrase de la clave debe estar vacía?

Para despliegues automatizados desde cPanel, sí: debe estar vacía porque nadie puede introducirla de forma interactiva. Para uso personal e interactivo, una passphrase añade seguridad. Si necesitas passphrase en entornos automatizados, la alternativa es ssh-agent, aunque su configuración en hosting compartido tiene limitaciones.

¿Puedo usar la misma clave SSH para varios repositorios?

Técnicamente sí, pero no es recomendable. Una clave por repositorio facilita la auditoría y la revocación selectiva. El coste de gestionar varias claves es bajo con un ~/.ssh/config bien organizado.

¿Cómo revoco el acceso cuando ya no lo necesito?

En el proveedor, ve a Deploy keys y elimina la entrada. La clave deja de funcionar inmediatamente. En el servidor, elimina también los archivos: rm ~/.ssh/mi-proyecto ~/.ssh/mi-proyecto.pub y borra la entrada de ~/.ssh/config.

¿Este proceso funciona igual en GitLab y Bitbucket?

Sí. Los pasos de generación de clave, configuración de ~/.ssh/config y clonado son idénticos. Solo cambia dónde registras la clave pública y la URL SSH: git@gitlab.com:usuario/repo.git para GitLab y git@bitbucket.org:usuario/repo.git para Bitbucket.

Hosting NVMe Nicalia