Guía de puertos SSH: acceso seguro al servidor remoto

SSH crea un canal cifrado entre un cliente y un servidor remoto. Durante la configuración de la conexión, el cliente verifica la clave del host del servidor, ambas partes negocian el cifrado y el usuario se autentica con una contraseña, clave SSH, certificado, clave respaldada por hardware u otro método configurado.

Después de la autenticación, SSH puede proporcionar un shell interactivo, ejecutar un único comando remoto, reenviar puertos, copiar archivos o herramientas eléctricas como Git, rsync, Ansible y canalizaciones de implementación. Esa flexibilidad es la razón por la cual SSH es operativamente importante y por qué la exposición necesita una política cuidadosa.

Abra SSH cuando los administradores, las herramientas de automatización, los trabajos de CI/CD, la gestión de configuración, los servicios Git o los flujos de trabajo innovadores necesiten acceso remoto a un servidor o dispositivo. Para los servidores de nube pública, SSH suele ser la primera ruta de administración utilizada antes de instalar herramientas de nivel superior.

No publique SSH en todo Internet si solo un grupo pequeño necesita acceso. Prefiera VPN, hosts bastión, acceso de confianza cero, consolas seriales en la nube, listas de IP de origen permitidas o conectividad de red privada cuando sea posible. Si el SSH público es inevitable, aplique una autenticación y supervisión sólidas desde el principio.

Antes de abrir el puerto 22, confirme que sshd se esté ejecutando, escuchando en la interfaz deseada y configurado para el modelo de autenticación que realmente desea. Decida si se permiten contraseñas, qué usuarios pueden iniciar sesión, si el inicio de sesión raíz está deshabilitado y cómo se auditarán las acciones administrativas.

Un verificador de puertos puede confirmar si se puede acceder a TCP 22 desde fuera de su red, pero no puede probar que un usuario pueda iniciar sesión de forma segura. Utilice ssh -vvv, registros del servidor y pruebas a nivel de cuenta para validar la confianza de la clave del host, los permisos de clave, las políticas de MFA, el acceso al shell y las reglas de sudo.

En Windows Server, instale y habilite OpenSSH Server, inicie el servicio sshd y permita TCP 22 entrante en Windows Defender Firewall. Los servidores Windows alojados en la nube también necesitan reglas de grupo de seguridad o firewall en la nube que coincidan.

En Linux, instale OpenSSH Server, verifique sshd_config y permita TCP 22 a través del firewall del host, como ufw, firewalld, nftables o iptables. Las instancias en la nube también requieren que el grupo de seguridad del proveedor permita las mismas redes de origen.

En macOS, habilite el inicio de sesión remoto cuando se necesite SSH en redes confiables. Para la exposición a Internet, aplique los mismos controles que un servidor: autenticación basada en claves, alcance del firewall, registro y actualizaciones oportunas.

Comience con una verificación del puerto externo con el nombre de host público o la dirección IP y el puerto 22. Si el resultado está abierto, se puede acceder a la ruta TCP a SSH. Luego ejecute ssh user@example.com o ssh -vvv user@example.com para verificar la clave del host, el método de autenticación y la configuración de la sesión.

En el servidor, confirme el oyente con ss -tlnp, netstat o PowerShell. Si hay un servidor en la nube involucrado, compare las reglas del firewall del host con el grupo de seguridad en la nube porque cualquiera de las capas puede bloquear SSH incluso cuando la otra parece correcta.

Si el puerto 22 está cerrado, sshd puede detenerse, instalarse en un puerto diferente, vincularse solo a una interfaz privada o bloquearse por el firewall del host. Si la verificación se agota, los paquetes pueden ser descartados por un grupo de seguridad en la nube, una regla NAT del enrutador, un filtro de ISP, una política de VPN o una lista de IP permitidas de origen.

Si el puerto está abierto pero el inicio de sesión falla, inspeccione el nombre de usuario, los permisos clave, el archivo de claves_autorizadas, la política de contraseñas, el requisito de MFA, las reglas AllowUsers o DenyUsers, la configuración de inicio de sesión raíz y los registros del servidor. Muchas fallas de SSH son problemas de autorización más que problemas de puerto.

Deshabilite el inicio de sesión raíz, prefiera claves o certificados a contraseñas, rote claves, elimine cuentas obsoletas y restrinja quién puede conectarse. Utilice MFA o claves respaldadas por hardware para obtener acceso privilegiado y asegúrese de que las claves privadas estén protegidas con frases de contraseña o almacenamiento de hardware seguro.

Reduzca la superficie de ataque con listas de fuentes permitidas, hosts bastión, VPN, limitación de velocidad, detección de intrusiones y parches OpenSSH oportunos. Mover SSH a un puerto no estándar puede reducir los escaneos ruidosos, pero debe tratarse sólo como una reducción de ruido, no como un control de seguridad.