Hola a tod@s,
Continuamos con los artículos sobre Azure Local. Después de revisar las novedades de Azure Local 2608, hoy vamos con una tarea muy concreta de operación: conectarnos por SSH a uno de los nodos del clúster.
Cuando pensamos en SSH solemos asociarlo directamente con Linux. Sin embargo, OpenSSH también está disponible en Windows y, combinado con Azure Arc, nos permite administrar equipos Windows mediante una conexión cifrada y sin necesidad de exponer una IP pública ni abrir el puerto 22 hacia Internet.
En esta guía utilizaremos el acceso SSH desde el portal de Azure. El nodo seguirá estando en nuestro datacenter, pero la conexión se establecerá mediante la capa de conectividad híbrida de Azure. Es una opción especialmente interesante para soporte, troubleshooting y administración remota controlada.
Importante: probad primero este procedimiento en un laboratorio o en un nodo no productivo. Habilitar SSH añade una vía de administración y debe integrarse con vuestro modelo de privilegios, auditoría y hardening.
Qué vamos a conseguir
- Comprobar que el nodo está registrado y conectado a Azure Arc.
- Validar o instalar OpenSSH Server y arrancar el servicio sshd.
- Registrar el proveedor Microsoft.HybridConnectivity.
- Instalar la extensión SSH de Azure CLI.
- Abrir una sesión con un usuario local mediante az ssh arc.
- Comprobar la identidad, el nodo y el estado del clúster desde la sesión remota.
Cómo funciona la conexión
El punto clave es que no necesitamos publicar el nodo en Internet. Azure Arc crea la ruta de conectividad para llegar al recurso Arc-enabled y la extensión de Azure CLI utiliza un proxy local para transportar la sesión SSH.
Ventaja operativa: el acceso SSH de Azure Arc funciona con servidores Windows y Linux, y no requiere una IP pública ni abrir puertos SSH entrantes adicionales.
Requisitos previos
- El nodo de Azure Local debe aparecer como servidor habilitado para Azure Arc y mantener el agente conectado.
- Hybrid Connected Machine Agent 1.31 o posterior.
- Servicio OpenSSH Server (sshd) habilitado en el nodo.
- Azure CLI 2.45.0 o posterior en el equipo desde el que nos conectaremos.
- Extensión ssh de Azure CLI actualizada. Microsoft requiere la versión 2.0.4 o posterior para az ssh arc.
- Permisos Owner o Contributor sobre el servidor habilitado para Azure Arc.
- Una cuenta local autorizada en el nodo y su método de autenticación: contraseña o clave privada.
Sobre Microsoft Entra ID: la autenticación SSH con certificados emitidos por Microsoft Entra se admite para Linux. En un nodo Windows utilizaremos una cuenta local, indicada con –local-user.
Variables que utilizaremos
Antes de empezar, identificamos el grupo de recursos y el nombre con el que el nodo aparece en Azure Arc. En los ejemplos voy a utilizar valores ficticios:
$ResourceGroup = «rg-azurelocal-lab»
$NodeName = «AL-NODE01»
$LocalUser = «sshadmin»
Paso 1. Comprobar OpenSSH Server en el nodo
Abrimos una consola de PowerShell con privilegios elevados directamente en el nodo, mediante consola física, iDRAC/iLO, Windows Admin Center o la vía de administración que ya tengamos disponible.
Get-WindowsCapability -Online | Where-Object Name -like «OpenSSH*»
Get-Service sshd -ErrorAction SilentlyContinue
Si OpenSSH Server no está instalado, lo añadimos como capacidad de Windows, aunque lo dudo que no esté instalado ya que es un requerimiento en el despliegue de Azure Local
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Tal como vemos en la imagen el OpenSSH Server esta disponible pero esta parado a continuación, iniciamos el servicio y configuramos el arranque automático:
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
Get-Service sshd | Select-Object Name, Status, StartType
Resultado esperado: el servicio sshd debe aparecer en estado Running y con inicio Automatic.
Paso 2. Preparar una cuenta administrativa dedicada
Para una primera prueba podemos utilizar una cuenta local existente. En producción es más recomendable crear una cuenta nominal o dedicada, aplicar una contraseña robusta o autenticación por clave, y retirar el acceso cuando termine la intervención.
$Password = Read-Host «Contraseña temporal» -AsSecureString
New-LocalUser -Name «sshadmin» -Password $Password -Description «Administración SSH autorizada»
Add-LocalGroupMember -Group «Administrators» -Member «sshadmin»
Seguridad: no incluyáis contraseñas en scripts, documentación o historiales de consola. Si utilizáis una cuenta temporal, definid un procedimiento para deshabilitarla o eliminarla después de la tarea.
OpenSSH suele crear una regla de firewall local. Podemos comprobarla de esta forma:
Get-NetFirewallRule -Name «OpenSSH-Server-In-TCP» -ErrorAction SilentlyContinue
Con Azure Arc no necesitamos publicar el puerto 22 en el perímetro. Aun así, sshd debe escuchar localmente en el nodo y cualquier política de firewall del propio sistema debe permitir el flujo necesario.
Paso 3. Preparar Azure CLI y la conectividad híbrida
En el equipo de administración, iniciamos sesión en Azure y seleccionamos la suscripción correcta:
az login –use-device-code
az account set –subscription «<ID-o-nombre-de-la-suscripcion>»
az account show –output table
Comprobamos si el proveedor Microsoft.HybridConnectivity está registrado:
az provider show –namespace Microsoft.HybridConnectivity –query registrationState –ouput tsv
Si el resultado no es Registered, lo registramos. Esta operación se realiza una vez por suscripción:
az provider register –namespace Microsoft.HybridConnectivity
Instalamos o actualizamos la extensión ssh:
az extension add –name ssh –upgrade
az extension show –name ssh –query version –output tsv
Comprobación crítica: aseguraos de utilizar la extensión ssh 2.0.4 o posterior. Versiones anteriores dejaron de funcionar con az ssh arc el 21 de mayo de 2025.
Paso 4. Conectarnos al nodo
Con el nodo preparado y la extensión instalada, ya podemos abrir la sesión mediante una cuenta local:
az ssh arc `
–resource-group $ResourceGroup `
–name $NodeName `
–local-user $LocalUser
Azure CLI resolverá el recurso de Azure Arc, preparará el endpoint de conectividad si es necesario y abrirá el cliente OpenSSH. Si usamos autenticación por contraseña, el cliente la solicitará de forma interactiva.
Si trabajamos con una clave privada, indicamos su ruta:
az ssh arc `
–resource-group $ResourceGroup `
–name $NodeName `
–local-user $LocalUser `
–private-key-file «$HOME\.ssh\id_ed25519»
Primera conexión: revisad la huella del host antes de aceptarla. En un entorno administrado, comparadla con una huella obtenida por una vía de confianza.
Paso 5. Validar que estamos en el nodo correcto
Una vez dentro no deberíamos empezar a ejecutar cambios directamente. Primero validamos identidad, privilegios y contexto:
whoami
hostname
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-ClusterNode
Get-ClusterGroup
Si queremos una comprobación rápida del estado general del clúster:
Get-ClusterNode | Format-Table Name, State
Get-StoragePool -IsPrimordial $false | Format-Table FriendlyName, HealthStatus, OperationalStatus
Get-VirtualDisk | Format-Table FriendlyName, HealthStatus, OperationalStatus
Buenas prácticas: utilizad la sesión SSH para diagnóstico y operaciones controladas. Para cambios de plataforma, firmware, drivers, red o ciclo de vida, seguid siempre el flujo soportado por Azure Local y el fabricante.
Errores habituales y cómo resolverlos
| Síntoma | Causa probable | Qué revisar |
| az: ssh no es un comando reconocido | Falta la extensión ssh o Azure CLI está desactualizada | Ejecutar az extension add –name ssh –upgrade y validar Azure CLI 2.45.0 o posterior. |
| AuthorizationFailed | La identidad no tiene permisos suficientes | Comprobar Owner o Contributor sobre el recurso Arc, su grupo de recursos o un ámbito superior. |
| HybridConnectivity no registrado | El proveedor no está registrado en la suscripción | Ejecutar az provider register –namespace Microsoft.HybridConnectivity y verificar el estado Registered. |
| Connection timed out | El agente Arc no está conectado o el endpoint no está listo | Revisar el estado Connected del servidor Arc, la salida de azcmagent show y la conectividad saliente requerida. |
| Connection refused | sshd no está iniciado o no escucha en el puerto configurado | Comprobar Get-Service sshd, reiniciar el servicio y revisar sshd_config y el firewall local. |
| Permission denied | Usuario, contraseña o clave incorrectos | Validar la cuenta local, la pertenencia a grupos y authorized_keys. Probar primero con una cuenta de laboratorio. |
| REMOTE HOST IDENTIFICATION HAS CHANGED | La clave de host guardada no coincide | No borrar known_hosts sin investigar. Verificar si hubo reinstalación, cambio de nodo o regeneración legítima de claves. |
Recomendaciones de hardening
- Aplicar mínimo privilegio y utilizar cuentas nominales. Evitar cuentas compartidas.
- Preferir claves SSH protegidas con passphrase frente a contraseñas para accesos recurrentes.
- Restringir quién puede operar el recurso Arc mediante Azure RBAC.
- Mantener Azure CLI, la extensión ssh, el agente Arc y OpenSSH actualizados.
- Revisar los registros de OpenSSH y de Windows cuando se produzcan intentos fallidos.
- No modificar componentes internos de Azure Local fuera de procedimientos soportados.
- Documentar el motivo, ventana y responsable de cada acceso privilegiado.
- Deshabilitar o retirar cuentas temporales después de la intervención.
Para finalizar
Con Azure Arc podemos conectarnos por SSH a un nodo de Azure Local sin publicar una IP pública ni abrir el puerto 22 hacia Internet. La experiencia es sencilla: habilitamos OpenSSH en el nodo, preparamos la conectividad híbrida, instalamos la extensión de Azure CLI y utilizamos az ssh arc con una cuenta local.
Lo más importante no es solo que la conexión funcione. Debemos tratarla como cualquier acceso privilegiado: mínimo privilegio, autenticación robusta, trazabilidad y una validación previa en laboratorio. Así convertimos SSH en una herramienta útil para troubleshooting sin introducir una excepción permanente en nuestro modelo de seguridad.
Ya sabemos cómo conectarnos mediante SSH a un nodo de un clúster de Azure Local. Nos vemos en el siguiente artículo.
Saludos.