Cómo conectarte por SSH a una VM de Azure

Si acabás de crear una máquina virtual en Azure con Linux y no sabés cómo entrar por consola, la respuesta es SSH: generás un par de claves (recomendado Ed25519), abrís el puerto 22 en las reglas de entrada y te conectás con ssh -i ~/.ssh/key.pem usuario@ip_publica. Todo el proceso está documentado en esta guía de dev.to.

SSH (Secure Shell) es un protocolo de la capa de aplicación que permite una conexión remota cifrada entre dos equipos, usando criptografía asimétrica para autenticar y después una clave simétrica para cifrar el resto del tráfico. Ese diseño en dos fases no es un detalle menor: la parte asimétrica es más lenta pero solo se usa una vez, al principio, para acordar una clave compartida sin exponerla en la red; la parte simétrica es rápida y es la que efectivamente cifra todo lo que escribís y ves en la terminal. Microsoft Azure lo integra de forma nativa: cuando creás una VM con autenticación por clave pública SSH, el puerto 22/TCP queda disponible para que te conectes desde cualquier terminal, sin contraseña de por medio.

¿Qué necesito antes de conectarme por SSH a una VM de Azure?

Necesitás tres cosas: una VM creada con autenticación por clave pública SSH, el archivo de clave privada (.pem) que Azure descarga en el momento de la creación, y el puerto 22 abierto en las reglas de entrada. Si falta alguno de los tres, la conexión no arranca.

Ponele que ya tenés la VM andando pero nunca elegiste el método de autenticación por clave, sino contraseña. En ese caso el flujo cambia: no hay .pem que mover ni permisos que ajustar, pero perdés la capa extra de seguridad que da la criptografía asimétrica. La guía de dev.to sobre SSH en Azure asume el escenario con clave, que es el que Microsoft recomienda por defecto.

¿Cómo creo una VM en Azure con autenticación SSH?

Se hace desde el portal de Azure, entrando a “Create a Resource” y seleccionando “Virtual machine”. El punto clave está en la sección Administrator Account: ahí elegís SSH public key como Authentication Type.

• Tipo de clave: Ed25519 es más rápido que RSA para generar y verificar firmas, así que es la opción recomendada salvo que necesites compatibilidad con un sistema viejo.
• Par de claves: podés generar uno nuevo desde el mismo asistente o usar uno existente si ya tenés claves de otro proyecto.
• Nombre del keypair: Azure te pide identificarlo, usá algo que te permita reconocerlo después entre varias VMs.
• Reglas de entrada: revisá que el puerto 22 esté abierto, si no lo está no vas a poder conectarte aunque todo lo demás esté bien configurado.

Criterio de decisión — Ed25519 vs. RSA: si estás armando un keypair nuevo y no tenés restricciones de compatibilidad, Ed25519 es la opción sensata por defecto porque produce claves más cortas y verificaciones más rápidas sin sacrificar seguridad. La única razón real para elegir RSA en su lugar es que necesites conectarte desde o hacia herramientas viejas que todavía no soportan Ed25519; si ese no es tu caso, no hay motivo para complicarse.

Una vez completada la configuración de red y almacenamiento, creás la VM. Ahí Azure te descarga automáticamente el archivo key.pem a tu computadora, ese archivo es tu única credencial de acceso. Te puede servir nuestra cobertura de si querés certificarte en Azure en 2026.

¿Cómo preparo el archivo .pem en mi computadora?

El archivo .pem que Azure descargó tiene que moverse a la carpeta ~/.ssh y quedar con permisos de solo lectura; si no, SSH directamente se niega a usarlo. Es una medida de seguridad del propio cliente SSH, no de Azure.

Si la carpeta ~/.ssh no existe todavía en tu equipo, la creás. Después movés el archivo ahí y cambiás los permisos:

chmod 400 ~/.ssh/key.pem

¿Por qué 400 y no otro valor? Porque le das permiso de lectura únicamente al dueño del archivo y le sacás cualquier acceso de escritura o ejecución, tanto para vos como para grupo y otros. Si tenés el .pem con permisos más abiertos, ssh va a rechazar la conexión con un error de “permissions too open” (sí, en serio, es así de estricto).

¿Cuál es el comando para conectarse por SSH a la VM?

La sintaxis general es ssh -i <path_to_key_file> <vm_name>@<vm_ip_addr>, donde el path apunta a tu archivo .pem y la IP es la dirección pública de la VM. Esa IP la sacás del portal de Azure, en el dashboard de la máquina virtual.

Un ejemplo concreto, tomado de la guía original: para una VM con usuario testvm e IP 102.113.114.200, el comando queda así:

ssh -i ~/.ssh/key.pem [email protected]

Subís la VM, copiás la IP del portal, armás el comando con tu usuario y tu ruta al .pem, lo tipeás en la terminal y en cuestión de segundos deberías estar viendo el prompt de la máquina remota, siempre que el puerto 22 esté abierto y los permisos del archivo estén bien puestos.

¿Cómo verifico el fingerprint del host antes de aceptar la conexión?

La primera vez que te conectás, SSH te muestra el fingerprint del host y te pregunta si confiás en él, eso pasa porque tu cliente todavía no tiene ese servidor en su lista de hosts conocidos. La respuesta correcta no es aceptar a ciegas: hay que comparar el fingerprint mostrado con el real de la VM.

El mensaje típico se ve así:

The authenticity of host '102.133.144.206 (102.133.144.206)' can't be established.
ED25519 key fingerprint is SHA256:bbZQo2Ph2ZV77Koob9iQT7i0G+oDNZVo9Q3fMg89T64.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

¿Alguien verifica esto en la práctica? Casi nadie, la mayoría tipea “yes” y sigue. Ese comportamiento tiene un nombre técnico: SSH funciona bajo un modelo de “confianza en el primer uso” (TOFU), donde el riesgo real no está en la primera conexión en sí, sino en que después el cliente va a confiar automáticamente en ese fingerprint para siempre. Si alguien lograra interceptar justo esa primera conexión, todas las siguientes quedarían comprometidas sin que lo notaras. Por eso, aunque acabás de crear la VM vos mismo, conviene confirmar que el fingerprint que te muestra la terminal coincide con el que tiene el servidor. Se hace corriendo esto directamente en la VM, desde Operations > Run Command > Run Shell Script en el portal de Azure: Relacionado: automatizar despliegues con service principal en Azure.

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub | awk '{print $2}'

Si los dos valores coinciden, escribís “yes” y quedás conectado. En la práctica, este chequeo importa más cuanto más sensible es lo que corre en esa VM: para una máquina de prueba descartable el costo de saltearlo es bajo, pero para un servidor de producción con datos reales conviene tratarlo como un paso obligatorio, no opcional.

Ejemplo hipotético: diagnosticar una conexión SSH que falla

Nota: el siguiente escenario es hipotético, pensado solo para ilustrar cómo aplicar los criterios anteriores a un caso de troubleshooting; no describe una VM ni un incidente real.

Imaginá que creaste una VM llamada webapp01, generaste tu keypair Ed25519, descargaste el .pem y al intentar conectarte con ssh -i ~/.ssh/webapp01.pem [email protected] la terminal se queda colgada sin responder nada, ni siquiera el mensaje de fingerprint. Siguiendo el orden de causas más comunes que vimos arriba, el diagnóstico sería así:

• Primero, el puerto: si la terminal se cuelga sin mostrar ningún mensaje (ni de fingerprint ni de error), lo más probable es que el puerto 22 no esté abierto en el grupo de seguridad de red de esa VM. Habría que revisar las reglas de entrada antes de tocar cualquier otra cosa.
• Si el puerto está abierto pero rechaza la clave: ahí el sospechoso pasa a ser los permisos del .pem. Un chmod 400 ~/.ssh/webapp01.pem resolvería ese caso puntual.
• Si conecta pero pide contraseña en vez de usar la clave: señal de que el usuario (admin en este ejemplo) no coincide con el que se definió al crear la VM.

El punto de este ejemplo no es memorizar el caso puntual, sino el orden de verificación: red primero, permisos del archivo después, usuario al final. Ese mismo orden sirve para cualquier VM real con síntomas parecidos.

Errores comunes al conectarse por SSH a una VM de Azure

• Permisos del .pem demasiado abiertos: si no corriste chmod 400, SSH rechaza la clave con un error de seguridad, aunque el archivo sea el correcto.
• Puerto 22 cerrado en el grupo de seguridad: la conexión se cuelga o directamente da timeout, esto pasa cuando se configuró la regla de entrada mal o se la borró después.
• Usar el nombre de usuario equivocado: el usuario tiene que coincidir exactamente con el que definiste al crear la VM, no con el de tu máquina local.
• Aceptar el fingerprint sin verificarlo: no rompe la conexión, pero te deja expuesto si alguien interceptó el tráfico entre tu terminal y la VM.
• Perder o borrar el archivo .pem: Azure no te lo vuelve a mostrar, si lo perdés vas a necesitar recurrir a algún método alternativo para volver a acceder a la VM.

Preguntas Frecuentes

¿Cómo me conecto por SSH a una VM de Azure?

Corrés ssh -i ~/.ssh/key.pem usuario@ip_publica desde tu terminal, usando la IP pública que figura en el dashboard de la VM en el portal de Azure. El archivo .pem tiene que estar en ~/.ssh/ con permisos chmod 400 y el puerto 22 abierto en las reglas de entrada.

¿Cómo genero una clave SSH para una máquina virtual en Azure?

Se genera durante la creación de la VM, eligiendo “SSH public key” como Authentication Type y seleccionando el tipo Ed25519. Azure crea el par de claves y descarga automáticamente el archivo .pem privado a tu computadora.

¿Qué puerto usa SSH en Azure y cómo lo abro?

SSH usa el puerto 22/TCP por defecto, tanto en Azure como en cualquier otro entorno. Se abre configurando una regla de entrada en el grupo de seguridad de red (NSG) asociado a la VM, permitiendo tráfico entrante en ese puerto. Sobre eso hablamos en cuando la nube reemplazó al escritorio tradicional.

¿Por qué no puedo conectarme por SSH a mi VM de Azure?

Las causas más comunes son permisos incorrectos en el archivo .pem (tiene que ser chmod 400), el puerto 22 cerrado en el NSG, o un nombre de usuario que no coincide con el definido al crear la VM. Revisá esos tres puntos en ese orden.

¿Cómo verifico el fingerprint del host al conectarme por SSH?

Corriendo ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub | awk '{print $2}' directamente en la VM, desde Operations > Run Command > Run Shell Script en el portal de Azure. Comparás ese valor con el fingerprint que te muestra tu terminal antes de aceptar la conexión.

Conclusión

Conectarse por SSH a una VM de Azure no tiene misterio una vez que entendés las tres piezas: clave con permisos correctos, puerto 22 abierto, y verificación del fingerprint en la primera conexión. Lo que cambia entre un intento fallido y uno exitoso suele ser un detalle chico, un permiso mal puesto o una regla de red que quedó afuera, y el orden en que se revisan esos detalles (red, permisos, usuario) suele ahorrar más tiempo que probar todo al azar.

Si administrás varias VMs, vale la pena guardar el fingerprint verificado la primera vez y documentar el proceso para el equipo, así nadie repite el mismo error dos veces. Los comandos y la sintaxis exacta de esta guía salen de la fuente original citada abajo; el orden de diagnóstico y el ejemplo de troubleshooting son una lectura propia aplicada a esos mismos pasos.

Fuentes

• Azure: SSH to a VM on Azure – dev.to, guía paso a paso con comandos y sintaxis