- El protocolo SSH garantiza una conexión cifrada y segura entre el equipo local y los servidores de Git, eliminando la necesidad de introducir contraseñas constantemente.
- La autenticación se basa en un par de claves asimétricas, donde la clave pública se comparte con el servidor y la privada se protege estrictamente en el equipo del usuario.
- Es posible gestionar múltiples identidades SSH simultáneamente para diferenciar cuentas personales y profesionales mediante la configuración de alias de host.
- La transición de HTTPS a SSH permite optimizar el flujo de trabajo y elevar los estándares de seguridad en el intercambio de código.
Cuando nos metemos en el mundo del desarrollo, gestionar el código en la nube es el pan de cada día. Aunque mucha gente empieza usando HTTPS por ser lo más sencillo, llega un punto en el que la autenticación mediante SSH se vuelve imprescindible para cualquiera que quiera trabajar de forma fluida y profesional, evitando el tedio de escribir credenciales a cada rato.
Básicamente, estamos hablando de crear un túnel seguro y cifrado entre nuestro PC y el servidor donde reside el proyecto. Usar SSH no es solo una cuestión de comodidad, sino una medida de seguridad robusta que protege nuestro trabajo frente a posibles intercepciones o ataques, permitiendo que solo las máquinas debidamente autorizadas puedan alterar los repositorios.
Entendiendo el funcionamiento de SSH en Git
Para que esto funcione, Git emplea un sistema de cifrado asimétrico. Esto significa que generamos un par de claves: una pública y otra privada. La clave pública es como un candado que dejamos en el servidor (ya sea GitHub, GitLab o Azure DevOps), mientras que la clave privada es la llave maestra que guardamos celosamente en nuestro equipo. Cuando intentamos hacer un push o un pull, el servidor comprueba que nuestra llave encaja con su candado y, si es así, nos deja pasar sin pedirnos más datos.
Una de las mayores ventajas es que este método es mucho más resistente a los troyanos o keyloggers que a los sistemas basados en contraseñas tradicionales. Además, una vez que el sistema está bien configurado, el acceso se vuelve permanente y transparente, lo que nos permite centrarnos en programar y no en gestionar accesos.
Cómo generar tus claves en Windows y otros sistemas
Si estás en Windows, lo más recomendable es utilizar Git Bash, ya que incluye toda la suite de herramientas OpenSSH necesaria. El comando fundamental para empezar es ssh-keygen -t rsa -b 3072. Al ejecutarlo, el sistema te preguntará dónde quieres guardar el archivo; lo más normal es dejar la ruta por defecto en la carpeta .ssh de tu usuario.
Un punto crítico aquí es la frase de seguridad o passphrase. Aunque puedes dejarla en blanco para mayor rapidez, añadir una contraseña a tu clave privada añade una capa de protección extra en caso de que alguien robe tu ordenador. En sistemas Linux o macOS, el proceso es idéntico ya que la terminal nativa ya trae estas herramientas integradas.
El papel del SSH-Agent y la gestión de claves
Si decidiste ponerle una frase de seguridad a tu clave, escribirla en cada operación puede ser un dolor de cabeza. Para solucionar esto usamos el ssh-agent, que actúa como un gestor de identidades que mantiene la clave cargada en memoria. En Windows, es vital asegurarse de que el servicio ssh-agent esté configurado en modo automático desde PowerShell con permisos de administrador.
Si notas que herramientas como VSCode te siguen pidiendo la contraseña a pesar de tener el agente activo, puede que necesites configurar la variable de entorno GIT_SSH. Esto le indica a Git exactamente qué ejecutable de OpenSSH debe utilizar para comunicarse con el agente del sistema y así evitar peticiones redundantes de autenticación.
Configuración en las plataformas principales
Una vez tienes tus archivos (normalmente id_rsa y id_rsa.pub), debes subir la versión pública al servidor. En GitHub, esto se hace desde la sección de Settings, entrando en SSH and GPG keys. Simplemente copias el contenido del archivo .pub y lo pegas allí asignándole un nombre descriptivo.
En el caso de Azure DevOps, el proceso es similar pero incluye un paso de validación adicional donde debemos comprobar la huella digital (fingerprint) del servidor para evitar ataques de suplantación. Es fundamental que la clave sea de tipo RSA y que esté correctamente asociada al perfil de usuario en el portal web para que el acceso sea concedido.
Trucos para manejar varias cuentas en una misma máquina
A veces nos ocurre que tenemos una cuenta de GitHub para el trabajo y otra para proyectos personales. Intentar usar la misma clave para ambas es imposible. El truco aquí consiste en crear archivos de configuración SSH personalizados. En la carpeta .ssh, creamos un archivo llamado config (sin extensión) donde definimos alias para cada host.
Por ejemplo, podemos crear un host llamado github.com-work y otro github.com-personal, asignando a cada uno su respectivo archivo de identidad (IdentityFile). Al clonar el repositorio, en lugar de usar la URL estándar, modificamos el host de la URL para que Git sepa qué clave debe presentar al servidor, permitiéndonos saltar de un perfil a otro sin conflictos.
Cambio de HTTPS a SSH en repositorios ya clonados
Si ya tienes un proyecto en tu PC pero lo bajaste usando HTTPS, no hace falta borrarlo y volverlo a clonar. Puedes actualizar la URL del remote origin usando el comando git remote set-url origin . Para obtener esta dirección, basta con ir a la pestaña de código del repositorio remoto y seleccionar la opción SSH.
Para comprobar que el cambio se ha realizado con éxito, ejecutamos git remote -v. Si vemos que la dirección ahora empieza por [email protected]... o similar, ya estamos operando bajo el protocolo seguro y no volveremos a ver el cuadro de diálogo pidiendo usuario y contraseña.
Integración con herramientas externas y despliegues
Herramientas como Sourcetree permiten gestionar estas claves desde su propia interfaz, cambiando el cliente SSH a OpenSSH y seleccionando manualmente la clave privada. Por otro lado, en entornos de despliegue como Plesk, el servidor genera su propia clave pública que nosotros debemos añadir a nuestro repositorio remoto para que el servidor pueda hacer pull de las actualizaciones automáticamente.
Es importante mencionar que algunas funciones, como Git LFS en ciertos servicios de Azure, podrían no ser compatibles totalmente con SSH, obligándonos a volver a HTTPS solo para esos archivos pesados. No obstante, para el flujo de trabajo diario de commits y pushes, SSH es la opción ganadora.
La implementación de claves SSH transforma la experiencia de desarrollo en Windows al eliminar fricciones de acceso y blindar la comunicación con los servidores. Desde la generación del par de claves y el uso del agente para gestionar contraseñas, hasta la configuración de alias para manejar múltiples cuentas y la migración de remotos de HTTPS a SSH, todo este ecosistema permite un control total sobre la seguridad y la eficiencia del flujo de trabajo en Git.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.