Ana ya tiene su remoto registrado. Escribe git push origin main con toda la ilusión y obtiene esto:

Un prompt esperando algo que no sabe muy bien qué es. Y si teclea la contraseña con la que entra en la interfaz web, es muy probable que reciba un rechazo del tipo Support for password authentication was removed.

Este muro detiene a mucha gente en su primer contacto con un repositorio remoto, y es una lástima, porque el problema no tiene nada que ver con Git: es un problema de identidad. Registrar una URL no da permiso para escribir en ella. Alguien tiene que demostrarle al servidor que es quien dice ser.

Esta lección resuelve ese muro de una vez y para siempre. Veremos por qué el clone de un repositorio público no pide nada y el push sí, los dos mecanismos de autenticación que se usan hoy —tokens sobre HTTPS y claves SSH—, cómo generar una clave con ssh-keygen, y cómo hacer que el sistema operativo recuerde las credenciales para no teclearlas cuarenta veces al día. Es la lección que Carla necesita antes de escribir su primera línea, porque entra desde Windows 11 y ahí el gestor de credenciales funciona de forma distinta.

1. Por qué el clone público no pide nada y el push sí
2. Autenticación frente a autorización
3. HTTPS con token personal de acceso
4. SSH: el par de claves
5. Generar la clave con ssh-keygen -t ed25519
6. Subir la pública, probar la conexión y usar el agente
7. ~/.ssh/config: varias identidades en la misma máquina
8. HTTPS frente a SSH: tabla comparativa
9. Gestores de credenciales por sistema operativo
10. Errores típicos y cómo diagnosticarlos

La respuesta es sencilla y despeja mucha confusión: son operaciones con requisitos de permiso distintos.

Un repositorio público es, por definición, legible por cualquiera. Descargar el código de un proyecto abierto no requiere identificarse, igual que leer una página web no requiere cuenta.

Escribir es otra historia. Cuando envías, le estás pidiendo al servidor que modifique sus referencias: que refs/heads/main pase a apuntar a otro commit. Eso cambia lo que todo el mundo verá al clonar a partir de ese momento. Ningún servidor sensato permite eso a un desconocido.

Y hay un matiz que sorprende a mucha gente: la identidad de Git y la identidad del servidor son cosas distintas.

Eso que configuraste en la lección 01-06 es metadato del commit: texto que se graba dentro del objeto y que aparece en git log. No autentica nada. Cualquiera puede poner cualquier nombre y cualquier correo en sus commits; Git no lo verifica.

La autenticación ocurre en otra capa: en el transporte, cuando tu Git habla con el servidor. Son dos identidades independientes que conviene no mezclar:

(Existe una forma de vincular ambas cosas de verdad, firmando los commits criptográficamente. Es un tema de seguridad y se trata en la lección 08-05.)

Dos palabras que se confunden a diario y que producen errores muy distintos:

• Autenticación: quién eres. Demostrar tu identidad ante el servidor.
• Autorización: qué puedes hacer. Los permisos que esa identidad tiene sobre ese repositorio concreto.

Puedes estar perfectamente autenticado y aun así recibir un rechazo:

Fíjate en el mensaje: el servidor sabe que eres Carla. La autenticación ha funcionado. Lo que falla es la autorización: a Carla no le han dado permiso de escritura en ese repositorio, o su token no tiene el ámbito necesario.

Distinguir los dos casos ahorra mucho tiempo:

Ese último caso es especialmente traicionero: Repository not found no significa necesariamente que hayas escrito mal la URL. Puede significar "existe, pero para ti no".

Un token personal de acceso (Personal Access Token, PAT) es una cadena larga generada por la plataforma que funciona como contraseña para un uso concreto. Tiene un aspecto parecido a este (ficticio, evidentemente):

Durante años, la autenticación por HTTPS se hacía con el usuario y la contraseña de la cuenta. GitHub retiró esa posibilidad en agosto de 2021 y el resto de plataformas siguió el mismo camino. Las razones son sólidas:

• Ámbito limitado. Tu contraseña abre toda la cuenta: repositorios, ajustes, facturación, borrado. Un token puede dar solo lectura de un repositorio concreto.
• Revocable individualmente. Si un token se filtra, lo eliminas y solo se rompe lo que lo usaba. Cambiar la contraseña te obliga a reconfigurar todo.
• Compatible con doble factor. Si tu cuenta tiene segundo factor, no hay forma de introducirlo en un prompt de Git. El token resuelve ese callejón sin salida.
• Caducidad. Un token puede expirar en 30, 60 o 90 días; una contraseña vive hasta que alguien se acuerda de cambiarla.
• Auditable. La plataforma registra qué token hizo qué y cuándo se usó por última vez.

El procedimiento concreto varía por plataforma, pero el esquema es siempre el mismo: ajustes de la cuenta → tokens de acceso → crear → elegir nombre, caducidad y ámbitos.

Los ámbitos son la parte importante. Concede el mínimo imprescindible:

Lo que casi nunca necesitas: ámbitos de administración, de gestión de usuarios, de borrado de repositorios o de acceso a los ajustes de la organización. Un token de despliegue que solo tiene que clonar no debería poder borrar nada.

Un consejo operativo: crea un token por máquina, no uno que compartas entre tu portátil, tu ordenador de casa y el servidor de integración continua. Si pierdes el portátil, revocas ese token y el resto sigue funcionando.

El token se introduce en el sitio de la contraseña:

En ese segundo prompt va el token, no la contraseña de la cuenta. Como no se ve mientras se escribe, es cómodo pegarlo desde el portapapeles.

Lo que no debes hacer nunca es incrustarlo en la URL:

Ese token acaba escrito en texto plano en .git/config, aparece en el historial de tu shell, se cuela en capturas de pantalla y sale en cualquier git remote -v que ejecutes delante de alguien. Para eso existen los gestores de credenciales del apartado 9.

La alternativa a HTTPS es SSH, y se basa en un concepto distinto: en lugar de un secreto compartido, se usa un par de claves asimétricas.

• La clave privada (~/.ssh/id_ed25519) se queda en tu máquina y no sale de ahí jamás. Es el equivalente a tu llave física.
• La clave pública (~/.ssh/id_ed25519.pub) se sube al servidor. Es el equivalente a la cerradura: se puede repartir sin riesgo.

La propiedad matemática que lo hace funcionar es que lo que se verifica con la pública solo lo ha podido producir la privada, y la privada no se puede deducir de la pública.

La ventaja sobre el token es evidente: el secreto nunca viaja por la red. Ni siquiera cifrado. Lo único que se transmite es una firma de un dato aleatorio distinto en cada conexión, inútil para un atacante que la capture.

Usa Ed25519 salvo que te encuentres con un servidor antiguo que lo rechace, en cuyo caso rsa con 4096 bits.

Carla, desde su Windows 11, abre Git Bash (que instaló en la lección 01-02 y que trae todas las herramientas de OpenSSH). Los comandos son idénticos en Linux, macOS y Git Bash:

Desglose de las opciones:

• -t ed25519: el tipo de clave. Es el argumento importante.
• -C "…": un comentario que se añade al final de la clave pública. Sirve para identificarla en la lista del servidor cuando tengas cuatro claves de cuatro máquinas. Puede ser el correo, pero es incluso mejor algo como "carla-portatil-windows", porque lo que quieres saber es de qué máquina es esa clave.

El diálogo:

Pulsa Intro para aceptar la ruta por defecto. Solo cámbiala si vas a tener varias claves, caso que veremos en el apartado 7.

Aquí hay que detenerse. La passphrase cifra la clave privada en el disco. Si alguien te roba el portátil o copia el fichero, sin ella la clave es inservible.

Ponla. Con ssh-agent, el coste real es teclearla una vez al arrancar el ordenador.

El resultado:

Dos ficheros. Veamos qué contienen:

Fíjate en los permisos, que son parte del mecanismo de seguridad:

• La privada es -rw------- (600): solo tú puedes leerla. Si tuviera permisos más abiertos, OpenSSH se negaría a usarla.
• La pública es -rw-r--r-- (644): legible por cualquiera, y no pasa nada.

Tres partes: el tipo, la clave en sí y el comentario. Esta línea es la que se sube al servidor, y se puede publicar sin ningún riesgo.

Y la privada, con la advertencia obvia:

Este contenido no se enseña, no se copia y no se envía a nadie. Nunca. Ni a un compañero, ni a soporte técnico, ni pegado en un chat. Si alguna vez tienes la duda de cuál de los dos ficheros hay que subir, la regla es infalible: el que acaba en .pub.

Se copia el contenido del .pub y se pega en la plataforma (ajustes de la cuenta → claves SSH → nueva clave). Para copiarlo al portapapeles:

Un aviso frecuente: al pegar, no debe quedar ningún salto de línea en medio. La clave es una sola línea larga; si el editor la parte, no funcionará.

Antes de intentar ningún comando de Git, comprueba que el canal funciona:

La opción -T significa "no quiero terminal interactiva": solo estoy comprobando la autenticación.

La primera vez aparece esto:

No respondas yes por inercia. Ese mensaje dice que tu ordenador no conoce todavía a ese servidor y te pide que confirmes que es el auténtico. Las plataformas publican sus huellas en su documentación; compárala antes de aceptar. Es la única defensa contra un ataque de intermediario en esa primera conexión.

Al aceptar, la huella se guarda en ~/.ssh/known_hosts y no volverá a preguntar.

Si todo va bien:

Ese mensaje es un éxito completo, aunque diga que no da acceso al shell. Eso es exactamente lo que debe pasar: el usuario git de un servidor de repositorios no sirve para abrir una sesión, solo para hablar Git.

Con passphrase, cada operación pediría la frase. El agente la guarda en memoria durante la sesión y responde por ti.

A partir de aquí, todos los push y pull funcionan sin teclear nada.

Cada sistema tiene su forma de dejarlo automatizado:

En Windows 11, el servicio ssh-agent viene con el sistema pero arranca desactivado. Desde PowerShell como administrador:

Y después, ya desde Git Bash:

Un detalle para Carla: si usa el ssh de Git Bash y el agente del sistema, pueden no verse entre sí. La solución sencilla es usar el bloque de ~/.bashrc de arriba, que arranca un agente propio de Git Bash.

Situación muy real, y precisamente la de Carla: en la lección 01-05 vimos que trabaja en dos contextos, el de ejemplo.es y el de otra empresa, con correos distintos. Si además cada uno exige una cuenta y una clave distintas, hace falta decirle a SSH cuál usar en cada caso.

Eso se resuelve en ~/.ssh/config:

Explicación de cada directiva:

IdentitiesOnly yes merece un comentario, porque evita un fallo desconcertante. Sin él, SSH ofrece todas tus claves una tras otra hasta que alguna funcione; si tienes cinco, el servidor puede cortar la conexión por exceso de intentos y obtendrás un Too many authentication failures que no parece tener nada que ver con la causa real.

El truco del alias inventado es lo que hace potente este fichero. Fíjate en Host git-otraempresa: ese nombre no existe en ningún DNS. Pero ahora Carla puede escribir:

Y SSH traduce git-otraempresa a git.otraempresa.es con la clave correcta. El mismo mecanismo sirve para dos cuentas en la misma plataforma, que es el caso clásico de tener una cuenta personal y otra de empresa en el mismo GitHub:

Mismo servidor real, dos identidades, sin ninguna ambigüedad.

Y para comprobar qué clave se va a usar realmente:

La opción -v (verbose) es la herramienta de diagnóstico definitiva para cualquier problema de SSH.

Permisos del fichero, que también son estrictos:

Las dos opciones son válidas y las dos se usan masivamente. La elección depende del contexto:

• Máquina de trabajo diaria, misma cuenta siempre → SSH. Se configura una vez y se olvida: no caduca, no se renueva y no interrumpe.
• Red corporativa con el puerto 22 cerrado → HTTPS + token. (Algunas plataformas ofrecen SSH por el puerto 443 como alternativa.)
• Integración continua, contenedores, servidores → Token con el ámbito mínimo y caducidad corta, o una clave de despliegue de solo lectura.
• Clonar un proyecto público para leerlo → HTTPS sin credenciales.
• Varias cuentas en la misma máquina → SSH con ~/.ssh/config.

Y un dato tranquilizador: cambiar de una a otra es un set-url, como vimos en la lección anterior:

No pierdes nada: los commits son los mismos, las referencias son las mismas y solo cambia el camino.

Con HTTPS queda un problema práctico: nadie va a teclear un token de 40 caracteres en cada push. Para eso existe credential.helper, que ya asomó en la lección 01-06 y que ahora podemos entender del todo.

Un credential helper es un programa externo al que Git le pregunta "¿tienes credenciales para este servidor?" antes de mostrar el prompt, y al que le dice "guárdate estas" cuando el acceso funciona.

Linux (Ana, Ubuntu) — libsecret

Se integra con el llavero del escritorio (GNOME Keyring, KWallet), que guarda los secretos cifrados y se desbloquea con la sesión:

En algunas distribuciones viene ya compilado y basta con instalar el paquete correspondiente.

macOS (Bruno) — osxkeychain

Viene incluido con Git en macOS; una sola línea:

Las credenciales se guardan en el Llavero, cifradas y visibles en la aplicación Acceso a Llaveros, donde se pueden revisar y borrar.

Windows 11 (Carla) — Git Credential Manager

Es el caso más interesante, y por eso lo dejamos para el final. GCM se instala junto con Git para Windows y queda configurado por defecto:

Lo que hace GCM va más allá de guardar una cadena:

• Guarda las credenciales en el Administrador de credenciales de Windows, cifradas con la cuenta de usuario del sistema.
• Abre una ventana de navegador para autenticarse contra GitHub, GitLab o Azure DevOps, con soporte para doble factor.
• Puede generar y renovar tokens por sí mismo, de modo que Carla no tiene que crear ninguno a mano.
• Es multiplataforma: existe también para Linux y macOS, aunque en esos sistemas los nativos suelen bastar.

Para Carla, esto significa que su primer git clone de un repositorio privado abrirá una ventana del navegador, ella entrará con su cuenta y su segundo factor, y a partir de ahí no volverá a ver un prompt. Es, con diferencia, la experiencia más cómoda de las tres.

Si quiere comprobar qué hay guardado, puede abrirlo desde Git Bash:

Las entradas de Git aparecen en la sección "Credenciales genéricas" con el prefijo git:.

Es tentador por lo fácil que es:

Y funciona a la primera. El problema se ve al mirar el fichero que crea:

Tu token, legible, en un fichero de tu carpeta personal. Sin cifrar, sin contraseña maestra, sin caducidad. Los permisos son 600, lo cual protege de otros usuarios de la misma máquina, pero no de:

• Cualquier programa que se ejecute con tu usuario, incluida una dependencia maliciosa de tu proyecto.
• Una copia de seguridad de tu carpeta personal que acabe en un disco externo o en la nube.
• Alguien que arranque el ordenador desde un USB o extraiga el disco.
• Un fichero de configuración sincronizado por error entre máquinas.

Cuándo no usarlo: en tu portátil, en tu ordenador de sobremesa, en cualquier máquina con acceso a repositorios que importen.

Cuándo podría tener sentido: en un contenedor efímero o una máquina virtual desechable, aislada, con un token de solo lectura y caducidad de horas, donde no hay ningún llavero disponible y el ciclo de vida de la máquina es más corto que el del token. Incluso ahí, casi siempre hay una opción mejor.

La alternativa razonable cuando no hay llavero es cache, que mantiene las credenciales en memoria durante un tiempo limitado:

Una hora sin volver a teclear, y nada tocando el disco. Al apagar, desaparece.

Todo lo relativo a la gestión de secretos, la firma de commits y el tratamiento de credenciales filtradas en el historial se desarrolla en la lección 08-05. Aquí nos hemos ocupado de lo operativo: poder trabajar de forma cómoda sin dejar secretos tirados.

Es el error de SSH más habitual. Significa: "El servidor no ha aceptado ninguna de las claves que le has ofrecido." Las causas, en orden de frecuencia:

Si responde Could not open a connection to your authentication agent, el agente no está en marcha:

Si responde The agent has no identities, está en marcha pero vacío: falta el ssh-add.

Compara esa huella con la que muestra la plataforma en la lista de claves. Si no coincide, subiste otra.

OpenSSH ignora en silencio las claves privadas con permisos demasiado abiertos, lo cual produce este error sin ninguna pista.

En la salida verás qué claves ofrece (Offering public key:) y cómo responde el servidor. Es la forma más rápida de descubrir que estás ofreciendo la clave equivocada.

Significa que la clave del servidor no coincide con la que tenías guardada en ~/.ssh/known_hosts. Hay dos explicaciones posibles:

1. Legítima: el servidor se ha reinstalado, se ha migrado o la plataforma ha rotado sus claves (ocurre de vez en cuando y siempre se anuncia públicamente).
2. Ataque de intermediario: alguien se está haciendo pasar por el servidor.

No borres la entrada sin comprobar. El procedimiento correcto:

La variante suave del mismo aviso —The authenticity of host … can't be established— es la primera conexión: no hay nada guardado todavía. También ahí conviene comparar la huella antes de aceptar.

Y un comando que resuelve el "no sé qué credencial está usando Git":

Muestra el proceso completo, incluido qué ayudante de credenciales se invoca. Úsalo solo para depurar y no compartas su salida sin revisarla, porque puede incluir cabeceras sensibles.

Error 1: subir la clave privada en lugar de la pública. Ocurre más de lo que parece. La regla es simple: se sube el fichero que termina en .pub. Si has subido la privada por error, bórrala del servidor, elimina el par entero de tu disco y genera uno nuevo: esa clave está comprometida para siempre.

Error 2: incrustar el token en la URL del remoto. Acaba en .git/config, en el historial de la shell y en cualquier captura de pantalla. Usa un gestor de credenciales.

Error 3: crear la clave sin passphrase "para ir rápido". El robo del portátil pasa de ser un problema de hardware a ser un problema de acceso a todos tus repositorios. Con ssh-agent, la passphrase se teclea una vez por sesión.

Error 4: confundir user.email con la identidad de acceso. Cambiar user.email no arregla ningún problema de autenticación: solo cambia el texto que aparece en los commits. Son capas distintas.

Error 5: aceptar la huella del servidor sin mirarla. Ese prompt de la primera conexión es la única oportunidad de detectar una suplantación. Las plataformas publican sus huellas; compararlas cuesta diez segundos.

Error 6: usar el mismo token en cinco máquinas. Cuando haya que revocarlo, se romperán las cinco a la vez y no sabrás cuál se filtró. Un token por máquina y por propósito.

Error 7: usar credential.helper store por defecto. Deja el token en texto plano en tu carpeta personal. Usa el gestor nativo de tu sistema, o cache si no hay ninguno disponible.

Consejo 1: prueba siempre con ssh -T antes de culpar a Git. Si ssh -T git@servidor funciona, el problema no está en SSH. Si no funciona, ssh -vT te dice exactamente en qué paso falla.

Consejo 2: pon un comentario útil en la clave. -C "carla-portatil-windows" es infinitamente más práctico que el correo cuando dentro de un año veas cuatro claves en la lista del servidor y tengas que decidir cuál revocar.

Consejo 3: apunta la caducidad de tus tokens. Un token que expira un lunes por la mañana genera media hora de desconcierto. Ponte un recordatorio unos días antes.

Consejo 4: IdentitiesOnly yes siempre que tengas más de una clave. Evita el Too many authentication failures, que es de los errores más difíciles de relacionar con su causa.

Consejo 5: para automatización, ámbito mínimo y caducidad corta. Un token de integración continua que solo tiene que clonar no necesita permiso de escritura ni de administración.

Sin subir nada a ningún servidor:

1. Genera un par Ed25519 en una ruta específica: ~/.ssh/practica_curso, con un comentario descriptivo.
2. Muestra los permisos de los dos ficheros y explica por qué son distintos.
3. Muestra la huella de la clave pública.
4. Cárgala en ssh-agent y verifica que aparece listada.
5. Comprueba que la huella de la clave privada y la de la pública coinciden. Explica por qué.
6. Descárgala del agente y elimina los ficheros.

Carla necesita trabajar con dos cuentas: la del equipo (git.ejemplo.es) y la de otra empresa (git.otraempresa.es).

1. Escribe el ~/.ssh/config completo para las dos, con claves separadas.
2. Explica qué hace cada directiva.
3. Escribe la URL de clonado que usaría para cada repositorio.
4. Indica el comando que le permitiría comprobar qué clave concreta se ofrece a cada servidor.
5. Explica qué pasaría si omitiera IdentitiesOnly yes y tuviera seis claves cargadas.

Para cada uno de estos mensajes, indica: (a) si el fallo es de autenticación o de autorización, (b) las dos causas más probables y (c) el comando o comprobación con el que empezarías.

1. [email protected]: Permission denied (publickey).
2. remote: Permission to equipo/gestor-tareas.git denied to carla.
3. remote: Support for password authentication was removed.
4. WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
5. ssh: connect to host git.ejemplo.es port 22: Connection timed out

Solución 1:

La opción -f fija la ruta y evita el diálogo de "dónde guardar".

La privada es 600: solo su dueño puede leerla, y OpenSSH se niega a usarla si tuviera permisos más laxos, porque cualquier otro usuario del sistema podría copiarla. La pública es 644 porque está diseñada para repartirse: no revela nada explotable.

Idénticas, y no es casualidad. La huella es un hash de la clave pública, y la pública se puede derivar de la privada (lo contrario no). Cuando ssh-keygen -lf recibe una clave privada, extrae la pública y calcula su huella. Por eso la huella sirve para emparejar sin ambigüedad qué privada de tu disco corresponde a qué pública subida al servidor: es exactamente la comprobación del apartado 10.

Solución 2:

1. El fichero ~/.ssh/config:

2. Qué hace cada directiva:

• Host: el nombre que Carla escribe en la URL. En el primer bloque coincide con el servidor real; en el segundo es un alias inventado que no existe en ningún DNS.
• HostName: el servidor real al que hay que conectarse. Es lo que resuelve el alias.
• User git: el usuario SSH. En las plataformas de repositorios es siempre git; el usuario real se deduce de la clave que presentas.
• IdentityFile: qué clave privada usar con este destino.
• IdentitiesOnly yes: usar solo esa clave, sin ofrecer las demás.
• AddKeysToAgent yes: cargarla en el agente al primer uso, para no repetir la passphrase.

3. Las URL de clonado:

4. Comprobar qué clave se ofrece:

Cada destino recibe exactamente una clave, la suya.

5. Sin IdentitiesOnly yes: SSH ofrecería todas las claves cargadas en el agente, una por una, en un orden que no controlas. Con seis claves y un servidor cuyo MaxAuthTries está en 6 (el valor habitual), es muy probable que agote los intentos antes de llegar a la correcta:

Un error especialmente traicionero, porque la clave correcta existe y está cargada: simplemente no le ha dado tiempo a probarla. Además, ofrecer todas tus claves a cualquier servidor con el que hables es una fuga de información innecesaria: le revelas cuántas identidades tienes.

Solución 3:

1. Permission denied (publickey)

• (a) Autenticación. El servidor no ha aceptado ninguna clave: ni siquiera sabe quién eres.
• (b) La clave no está cargada en el agente, o la que tienes en el disco no es la que está subida al servidor. Menos frecuente pero muy desconcertante: permisos demasiado abiertos en la privada, que hacen que OpenSSH la ignore en silencio.
• (c) ssh-add -l para ver qué hay cargado y, si eso no aclara nada, ssh -vT [email protected] para ver qué clave se ofrece y cómo responde el servidor.

2. Permission to equipo/gestor-tareas.git denied to carla

• (a) Autorización. El mensaje nombra a Carla, así que la autenticación ha funcionado perfectamente.
• (b) Su cuenta no tiene permiso de escritura en ese repositorio, o —si va por HTTPS con token— el token carece del ámbito de escritura.
• (c) Revisar los permisos de la cuenta en la configuración del repositorio y los ámbitos del token en la plataforma. No hay ningún comando de Git que arregle esto: es un cambio en el servidor.

3. Support for password authentication was removed

• (a) Autenticación. Se está enviando un método que el servidor ya no admite.
• (b) Se ha tecleado la contraseña de la cuenta en lugar de un token; o hay una credencial antigua guardada en el gestor, con la contraseña de antes de la migración.
• (c) Generar un token con el ámbito necesario y, muy importante, borrar la credencial guardada antes de reintentar, o el gestor volverá a enviar la vieja:

4. REMOTE HOST IDENTIFICATION HAS CHANGED!

• (a) Autenticación, pero en el sentido inverso: es el servidor el que no consigue demostrar su identidad ante ti.
• (b) El servidor se ha reinstalado o la plataforma ha rotado sus claves (lo normal); o alguien está interceptando la conexión (lo grave).
• (c) Obtener la huella actual y compararla con la publicada oficialmente antes de tocar nada:

Solo si coincide con la oficial: ssh-keygen -R git.ejemplo.es y reconectar.

5. connect to host … port 22: Connection timed out

• (a) Ninguna de las dos: es un problema de red. La conexión no llega a establecerse, así que no hay ni autenticación ni autorización.
• (b) Un cortafuegos corporativo con el puerto 22 cerrado (lo más habitual con diferencia), o el servidor caído.
• (c) Comprobar la conectividad y, si es el cortafuegos, cambiar de vía:

Algunas plataformas ofrecen además SSH por el puerto 443, que atraviesa esos cortafuegos:

Con esta lección el equipo puede por fin hablar con el servidor. Lo esencial:

• Leer un repositorio público no requiere credenciales; escribir siempre sí, porque push modifica las referencias del servidor.
• user.name y user.email no autentican nada: son metadatos del commit. La identidad de acceso vive en otra capa.
• Autenticación (quién eres) y autorización (qué puedes hacer) son distintas. Permission denied (publickey) es lo primero; 403 Forbidden es lo segundo. Distinguirlas dirige el diagnóstico.
• HTTPS se autentica con un token personal de acceso, que sustituyó a la contraseña por ser de ámbito limitado, revocable, caducable, auditable y compatible con doble factor. Concede siempre el ámbito mínimo y usa un token por máquina.
• SSH se autentica con un par de claves: la privada nunca sale de tu disco, la pública se sube al servidor. Genera con ssh-keygen -t ed25519 -C "descripción", pon passphrase, sube el fichero .pub, prueba con ssh -T y usa ssh-agent para teclearla una sola vez.
• ~/.ssh/config resuelve el caso de varias identidades, incluso dos cuentas en el mismo servidor, mediante alias inventados. IdentitiesOnly yes evita el Too many authentication failures.
• HTTPS frente a SSH: HTTPS gana en cortafuegos corporativos y en granularidad de permisos; SSH gana en comodidad diaria, en no caducar y en manejar varias identidades. Cambiar de uno a otro es un git remote set-url.
• Cada sistema tiene su gestor de credenciales: libsecret en Linux, osxkeychain en macOS y Git Credential Manager en Windows, que además abre el navegador y gestiona los tokens por ti: el camino de Carla.
• credential.helper store guarda el token en texto plano en ~/.git-credentials. Evítalo en máquinas reales; si no hay llavero, cache con tiempo de espera es mejor opción.
• Para lo demás —firma de commits, gestión de secretos, credenciales filtradas en el historial— la lección 08-05.

Ana, Bruno y Carla ya pueden autenticarse. El canal está abierto en los dos sentidos y, por primera vez en el curso, los objetos pueden viajar de un .git/ a otro.

En la lección 04-04: Obteniendo y Extrayendo Cambios empezamos a usarlo en el sentido de la recepción, y atacamos de frente la confusión más extendida de Git: la diferencia entre git fetch y git pull. Veremos por qué fetch no toca jamás tu directorio de trabajo, qué es FETCH_HEAD, cómo inspeccionar lo que ha llegado antes de integrarlo, y los distintos modos de git pull. Y por fin Carla clona gestor-tareas y se pone al día con el trabajo de sus compañeros.