Café recién tirado en la taza, terminal abierta en una pestaña, la lista de tareas del sprint mirándote con cara de pocos amigos y tú tirando un rutinario git fetch para comprobar si las ramas están al día. Todo normal, ¿verdad?

Hasta que la consola, en vez del habitual silencio administrativo que tanto nos gusta a los que picamos código, decide escupirte una pullita con nocturnidad y alevosía:

Starting November 12, 2026, Bitbucket is moving SSH traffic to ssh.bitbucket.org. 
Change your host name now to avoid connection disruptions.

(Silencio dramático. Trago largo de café).

Si eres de los que cierran la pestaña pensando «ya lo miraré luego, seguro que es la típica turra corporativa», frena en seco. Porque esta vez los amigos de Atlassian no vienen con fuegos artificiales ni con encuestas de satisfacción: vienen con las tijeras de podar.

Mañana mismo empiezan las hostilidades. Y si no tocas cuatro líneas tontas, tu pipeline de CI/CD o tu despliegue de las 13:00 van a reventar de la forma más rastrera y cobarde que conoce la informática moderna: el fallo intermitente.

📦 ¿Qué demonios está cambiando Atlassian?

Vamos al grano y sin florituras teóricas.

1. El SSH se muda de portal: Todo el tráfico Git por SSH deja de funcionar en bitbucket.org y pasa obligatoriamente a ssh.bitbucket.org.
2. HTTPS se queda donde estaba: La interfaz web, la API REST y los clones vía HTTPS no se mueven de bitbucket.org.
3. Mismas claves de host, pero aviso garantizado: Aunque Atlassian usa las mismas firmas para ambos hosts, tu cliente SSH trata a ssh.bitbucket.org como un completo desconocido si solo tenías guardado bitbucket.org. Así que sí: la primera vez que conectes, el aviso de autenticidad te va a saltar en la cara.

¿Por qué hacen esto ahora? En sus comunicados oficiales se limitan a darte la fecha y el nuevo dominio, sin despeinarse. Lo de siempre: cero explicaciones de trinchera. Lo más probable (y esto es deducción de perro viejo tras lidiar con infraestructuras saturadas) es que quieran desacoplar el chorro bestial de conexiones SSH del tráfico web y de balanceadores para poder escalarlo y gestionarlo por separado sin que un pico de peticiones tire el portal.

😱 El aviso del fingerprint: Que no cunda el pánico (pero casi)

Si te has adelantado al apocalipsis y has probado a conectar contra ssh.bitbucket.org, es muy probable que tu terminal te haya soltado el clásico bofetón de seguridad:

The authenticity of host 'ssh.bitbucket.org (…)' can't be established.
ED25519 key fingerprint is SHA256:y9wnk5p5e6eQJ6K…
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Tranquilidad en las masas: Las claves públicas son legítimas, pero como tu cliente SSH nunca se había hablado con el subdominio ssh.bitbucket.org, tu archivo local ~/.ssh/known_hosts no lo tiene fichado y por defecto salta la alarma.

Para dejarlo niquelado y no andar dándole al «yes» a ciegas en cada servidor como si no hubiera un mañana, mete la huella oficial de Atlassian a mano antes de que tus scripts de despliegue se queden pillados esperando una respuesta interactiva que nunca llegará:

# Limpia por si acaso alguna prueba anterior te ha dejado basura
ssh-keygen -R ssh.bitbucket.org 2>/dev/null

# Consulta las huellas oficiales de Bitbucket y añádelas a tu known_hosts
ssh-keyscan -t ed25519,rsa ssh.bitbucket.org >> ~/.ssh/known_hosts

Regla de oro de perro viejo: No te fíes de mi comando ni del que te pase nadie en un foro. Pásate por la documentación oficial de Atlassian (bitbucket.org/site/ssh) y verifica con tus propios ojos que el hash que te escupe coincide letra por letra.

💣 La tortura medieval de los «Brownouts» (o cómo volverte loco depurando)

Atlassian no va a bajar el interruptor general de golpe. Eso sería demasiado compasivo. Han decidido aplicar la táctica del novio tóxico: cortes programados progresivos (brownouts).

Básicamente, tirarán el servicio SSH en bitbucket.org durante ventanas de tiempo específicas cuatro veces al día (a las 00:00, 06:00, 12:00 y 18:00 UTC; es decir, 01:00, 07:00, 13:00 y 19:00 en España), de lunes a viernes:

Fechas (2026)	Duración de cada corte	Estado de tu salud mental
12–13 nov	15 minutos	«Qué raro, habrá sido un microcorte del router»
16–20 nov	30 minutos	«Oye, el Capistrano me ha dado timeout pero luego ha colado»
23–24 nov	1 hora	«Reinicio la VPN por si las moscas»
30 nov – 2 dic	2 horas	Pánico en el canal de Slack
3–4 y 7–9 dic	3 horas	Desesperación pura y dura
10 de diciembre	Muerte definitiva	Apagón total del SSH en el host antiguo

(Se saltan los fines de semana y la tregua del 25 al 27 de noviembre por Acción de Gracias, qué detalle por su parte).

¿Ves el peligro? Si lanzas un despliegue justo a las 13:05, tu Capistrano, tu Ansible o tu runner de CI/CD se pegará una hostia monumental al clonar o hacer checkout. Diez minutos después repites el comando, funciona como la seda y te quedas media hora mirando los logs de red como una vaca mirando al tren, jurando en arameo porque piensas que el switch de tu proveedor está poseído.

Y el 10 de diciembre… se acabó el juego. Quien no haya migrado, no despliega. Punto.

🛠️ Al lío: Cómo arreglarlo en 30 segundos

Para solucionarlo solo tienes que cambiar los remotes configurados de tu repo.

# Comprueba cómo lo tienes ahora
git remote -v

# Cámbialo al nuevo host
git remote set-url origin git@ssh.bitbucket.org:tu-cuenta/tu-repo.git

Y lo compruebas así:

ssh -Tv git@ssh.bitbucket.org

Si te devuelve el saludo oficial confirmando la autenticación, ya estás a salvo de la quema.

No lo dejes para el viernes a última hora. Pásate por tus servidores de integración, revisa los entornos de staging, dale un repaso a tu portátil y deja el SSH bien atado hoy mismo. Que las canas en esto del desarrollo están para anticiparse al incendio, no para pasarse la tarde apagándolo con cubos de agua.

¡A picar código fino, y que el demonio de SSH os pille confesados! 🤘🔥