SSH Access: La Guía Técnica Completa para la Gestión Segura de Servidores Remotos

SSH (Secure Shell) es un protocolo de red criptográfico que establece un túnel cifrado entre dos hosts en red, permitiendo la ejecución autenticada de comandos, transferencia de archivos y reenvío de puertos a través de redes no confiables. Opera en el puerto TCP 22 de forma predeterminada y reemplaza a los predecesores de texto plano — Telnet, rsh y FTP — con un protocolo que proporciona confidencialidad, integridad y autenticación mutua en un único handshake.

Para cualquier administrador que gestione un VPS o un servidor dedicado, SSH no es infraestructura opcional — es el plano de control principal. Cada decisión de configuración que tome en torno a SSH afecta directamente la superficie de ataque de su servidor, la fiabilidad operativa y la postura de cumplimiento.

Cómo funciona SSH: La arquitectura del protocolo

Comprender SSH a nivel de protocolo es lo que separa a los administradores que lo configuran correctamente de aquellos que dejan brechas explotables.

El modelo de tres capas

SSH está definido por RFC 4251–4254 y opera a través de tres subcapas distintas apiladas sobre TCP:

• Protocolo de capa de transporte SSH — gestiona la autenticación del servidor, el intercambio de claves, la negociación de cifrado y la configuración de MAC (código de autenticación de mensajes). Aquí es donde ocurre el handshake criptográfico.
• Protocolo de autenticación de usuario SSH — se ejecuta sobre la capa de transporte y gestiona la autenticación del cliente al servidor utilizando métodos como publickey, password, keyboard-interactive o gssapi-with-mic.
• Protocolo de conexión SSH — multiplexa el túnel cifrado en canales lógicos, cada uno transportando una sesión de shell, un subsistema SFTP, un puerto reenviado o una conexión de agente.

El handshake en detalle

Cuando ejecuta ssh user@host, la siguiente secuencia se ejecuta antes de que vea un prompt:

1. Se establece la conexión TCP al servidor en el puerto configurado.
2. Intercambio de versiones — el cliente y el servidor intercambian cadenas de versión del protocolo (SSH-2.0-OpenSSH_9.x).
3. Negociación de algoritmos (SSH_MSG_KEXINIT) — ambas partes anuncian los algoritmos de intercambio de claves compatibles, tipos de clave de host, cifrados, MACs y métodos de compresión. La primera opción mutuamente compatible en cada lista gana.
4. Intercambio de claves (KEX) — típicamente Diffie-Hellman o Elliptic Curve Diffie-Hellman (ECDH). Ambas partes derivan un secreto compartido sin transmitirlo. Esto produce claves de sesión.
5. Verificación de la clave de host del servidor — el servidor firma un valor con su clave de host privada. El cliente verifica esta firma contra su archivo ~/.ssh/known_hosts. Una discrepancia activa una advertencia y bloquea la conexión de forma predeterminada.
6. Cifrado activado — todo el tráfico posterior está cifrado y protegido en integridad utilizando el cifrado negociado (p. ej., chacha20-poly1305) y MAC.
7. Autenticación de usuario — el cliente intenta autenticarse utilizando el método negociado. Con la autenticación publickey, el cliente firma un desafío con su clave privada; el servidor verifica usando la clave pública almacenada.
8. Apertura de canal — se abre un canal de shell, subsistema SFTP o exec y comienza la sesión.

Todo este proceso generalmente se completa en menos de 100 milisegundos en una red local.

Criptografía simétrica vs. asimétrica en SSH

Un malentendido común es que SSH “usa cifrado de clave pública” para todo el tráfico. No es así. Los roles son distintos:

SSH vs. protocolos de acceso remoto heredados

Generación de pares de claves SSH

Los pares de claves SSH son la base del acceso seguro y escalable a servidores. La autenticación por contraseña es vulnerable a ataques de fuerza bruta y relleno de credenciales; la autenticación basada en claves no lo es.

Elegir el algoritmo de clave correcto

Ed25519 es la mejor práctica actual. Utiliza criptografía de curva elíptica Curve25519, produce claves compactas de 256 bits, es más rápido que RSA en niveles de seguridad equivalentes y es compatible con OpenSSH 6.5+ (lanzado en 2014).

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

Use RSA solo cuando necesite compatibilidad con sistemas heredados que no admiten Ed25519:

ssh-keygen -t rsa -b 4096 -C "admin@yourhost.example.com"

No use DSA (limitado a 1024 bits, comprometido) ni ECDSA con curvas NIST (preocupaciones sobre la procedencia de los parámetros de curva NIST). Ed25519 es la elección inequívoca para nuevas implementaciones.

Guía de generación de claves

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Se le solicitará:

• Ubicación del archivo — el valor predeterminado es ~/.ssh/id_ed25519. Acepte el valor predeterminado o especifique una ruta personalizada para entornos con múltiples claves.
• Frase de contraseña — establezca siempre una. Una frase de contraseña cifra la clave privada en reposo usando AES-256-CBC (o bcrypt con OpenSSH más reciente). Si su archivo de clave privada es robado, la frase de contraseña es la última línea de defensa.

Esto produce dos archivos:

~/.ssh/id_ed25519 — la clave privada. Nunca la comparta. Los permisos deben ser 600.
~/.ssh/id_ed25519.pub — la clave pública. Esto es lo que distribuye a los servidores.

Gestión de múltiples claves con ~/.ssh/config
Al gestionar múltiples servidores o cuentas, use un archivo de configuración SSH para evitar especificar indicadores en cada conexión:
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
Con esto en su lugar, ssh prod-web se expande automáticamente a los parámetros de conexión completos.
Implementación de su clave pública en un servidor
Método 1: ssh-copy-id (Recomendado para la configuración inicial)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Esto agrega la clave pública a ~/.ssh/authorized_keys en el host remoto y establece los permisos correctos automáticamente.
Método 2: Implementación manual (cuando ssh-copy-id no está disponible)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Método 3: Consola o API del proveedor de nube
La mayoría de los proveedores de nube y paneles de control de alojamiento le permiten inyectar claves públicas durante el aprovisionamiento de instancias. Este es el enfoque correcto para infraestructura automatizada — la clave está presente antes de que la instancia arranque, eliminando el problema del huevo y la gallina de necesitar SSH para implementar claves SSH.
El formato del archivo authorized_keys
Cada línea en ~/.ssh/authorized_keys es una clave pública, opcionalmente precedida por opciones:
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
La opción restrict deshabilita el reenvío de puertos, el reenvío de agente y la asignación de PTY para esa clave — útil para claves de implementación o cuentas de automatización de respaldo que no deberían tener acceso interactivo al shell.
Fortalecimiento del servidor SSH: /etc/ssh/sshd_config
Una instalación predeterminada de OpenSSH es funcional pero no está reforzada. La siguiente configuración representa una línea base de nivel de producción. Aplique los cambios a /etc/ssh/sshd_config, luego valide y recargue:
sshd -t && systemctl reload sshd
Siempre ejecute sshd -t antes de recargar — un error de sintaxis en sshd_config no bloqueará el daemon en ejecución, pero impedirá que se reinicie después de un reinicio, dejándole sin acceso.
Bloque de refuerzo recomendado para sshd_config
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Decisiones críticas de refuerzo explicadas
PermitRootLogin no — El inicio de sesión root a través de SSH es un objetivo de alto valor. Use un usuario regular y escale con sudo. Si absolutamente necesita acceso equivalente a root a través de una clave específica (p. ej., para automatización), use PermitRootLogin prohibit-password para permitir el inicio de sesión root solo con clave mientras bloquea los intentos con contraseña.
AllowTcpForwarding no — Si su servidor no es un bastión o host de salto, deshabilite el reenvío TCP. Un atacante con una sesión SSH válida podría de otro modo usar su servidor como proxy para acceder a recursos de red interna.
TCPKeepAlive no con ClientAliveInterval — TCPKeepAlive opera en la capa TCP y es visible para los intermediarios de red. ClientAliveInterval envía mensajes de keepalive a través del canal SSH cifrado, lo que es tanto más confiable como más privado.
LoginGraceTime 30 — Reduce la ventana durante la cual una conexión no autenticada ocupa un slot del servidor. El valor predeterminado de 120 segundos es excesivo.
AllowUsers — Incluya en la lista blanca solo las cuentas que legítimamente necesitan acceso SSH. Esta es una barrera estricta que opera antes de cualquier intento de autenticación.
Cambio del puerto SSH predeterminado
Mover SSH fuera del puerto 22 no mejora la seguridad contra un atacante dirigido — cualquier escaneo de puertos lo encontrará. Lo que sí hace es eliminar el enorme volumen de bots automatizados y oportunistas de fuerza bruta que atacan exclusivamente el puerto 22. Esto reduce significativamente el ruido de los registros y la carga del servidor.
# In /etc/ssh/sshd_config
Port 2222
Antes de recargar, abra el nuevo puerto en su firewall:
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Si su servidor ejecuta SELinux, también debe actualizar el contexto de puerto SELinux:
semanage port -a -t ssh_port_t -p tcp 2222
Conexión a un servidor
Conexión básica
ssh user@your_server_ip
Conexión a un puerto no predeterminado
ssh -p 2222 user@your_server_ip
Conexión con una clave específica
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Modo detallado para depuración
ssh -vvv user@your_server_ip
El indicador -vvv imprime cada paso del handshake, el intento de autenticación y la negociación de canal. Es la primera herramienta a la que recurrir cuando una conexión falla inesperadamente.
Transferencias seguras de archivos a través de SSH
SCP (Protocolo de copia segura)
SCP es una herramienta de copia de archivos simple y no interactiva. Es rápida y ampliamente disponible, pero no tiene capacidad de reanudación y manejo de errores limitado.
Copiar un archivo local a un servidor remoto:
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Copiar un archivo remoto a local:
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Copia recursiva de directorio:
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Nota: El proyecto OpenSSH deprecó el protocolo SCP heredado en OpenSSH 9.0. El scp moderno ahora usa el protocolo SFTP de forma predeterminada. La interfaz de comandos sigue siendo la misma, pero el transporte subyacente es más robusto.
SFTP (Protocolo de transferencia de archivos SSH)
SFTP es un subsistema de transferencia de archivos con todas las funciones, con listado de directorios, gestión de permisos y soporte de reanudación. Es la opción correcta para la gestión interactiva de archivos.
sftp -P 2222 user@your_server_ip
Comandos SFTP comunes dentro de la sesión interactiva:
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
rsync sobre SSH (Recomendación de producción)
Para sincronizar directorios, copias de seguridad incrementales o grandes conjuntos de datos, rsync sobre SSH es significativamente más eficiente que SCP o SFTP. Transfiere solo los bloques modificados, no archivos completos.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
El indicador -z habilita la compresión en tránsito. Para datos ya comprimidos (archivos, imágenes), omítalo — la compresión de datos ya comprimidos desperdicia CPU sin reducir el tamaño de transferencia.
Reenvío de puertos SSH y tunelización
El reenvío de puertos es una de las capacidades más poderosas y subutilizadas de SSH. Le permite acceder de forma segura a servicios que no están directamente expuestos a internet.
Reenvío de puertos local
Reenvíe un puerto local a un servicio remoto. Ejemplo: acceda a una instancia MySQL remota (puerto 3306) que está vinculada a localhost en el servidor:
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Ahora mysql -h 127.0.0.1 -P 3307 en su máquina local se conecta a través del túnel cifrado al MySQL remoto.
Reenvío de puertos remoto
Exponga un servicio local al servidor remoto. Útil para probar webhooks o compartir un servidor de desarrollo local:
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Reenvío de puertos dinámico (proxy SOCKS)
Convierta la conexión SSH en un proxy SOCKS5, enrutando tráfico TCP arbitrario a través del servidor:
ssh -D 1080 user@your_server_ip -N
Configure su navegador o aplicación para usar SOCKS5 127.0.0.1:1080.
Agente SSH y reenvío de agente
ssh-agent mantiene las claves privadas descifradas en memoria para que no tenga que volver a ingresar su frase de contraseña en cada conexión.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
El reenvío de agente (ssh -A) permite que un servidor remoto use su agente local para autenticarse en un tercer servidor. Esto es útil para arquitecturas de host bastión, pero conlleva riesgos: un usuario root en el servidor intermedio puede usar su socket de agente reenviado. Prefiera ProxyJump en su lugar:
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump enruta la conexión TCP a través del bastión sin exponer su agente a él.
Solución de problemas comunes de SSH
Conexión rechazada (ssh: connect to host ... port 22: Connection refused)
Diagnóstico sistemático:

Verifique que el daemon SSH esté en ejecución: systemctl status sshd

• Confirme el puerto de escucha: ss -tlnp | grep sshd
• Verifique las reglas del firewall: ufw status o iptables -L -n | grep 22
• Verifique que el servidor sea accesible a nivel de red: ping your_server_ip
• Si usa un proveedor de nube, verifique las reglas del grupo de seguridad o ACL de red en la consola del proveedor.

Permiso denegado (publickey)

Este es el error SSH más común. Siga esta lista de verificación:

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

Causas comunes más allá de los permisos:

• El archivo authorized_keys contiene la clave incorrecta (p. ej., copió la clave privada en lugar del archivo .pub).

StrictModes yes en sshd_config (el valor predeterminado) rechaza conexiones si los permisos del directorio home son demasiado abiertos — chmod 755 ~ es el máximo permitido.
AllowUsers o AllowGroups en sshd_config excluye al usuario que se conecta.
SELinux está bloqueando el acceso a ~/.ssh/ — verifique ausearch -m avc -ts recent.

Tiempo de espera de conexión SSH
# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
ClientAliveInterval envía un paquete nulo a través del canal SSH cifrado cada 60 segundos. Después de ClientAliveCountMax respuestas perdidas consecutivas, el servidor termina la conexión. Esto evita que se acumulen sesiones zombie.
Verificación de clave de host fallida
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Esta advertencia significa que la clave de host del servidor ya no coincide con lo almacenado en ~/.ssh/known_hosts. Las causas legítimas incluyen la reinstalación del servidor o la reasignación de direcciones IP. Las causas maliciosas incluyen un ataque de intermediario. Investigue antes de continuar.
Si ha confirmado que el servidor fue reinstalado legítimamente:
ssh-keygen -R your_server_ip
Luego reconéctese y verifique la huella digital de la nueva clave de host contra la consola del servidor o el panel del proveedor antes de aceptarla.
Autenticación multifactor para SSH
La autenticación basada en claves es sólida, pero agregar un segundo factor TOTP (Contraseña de un solo uso basada en tiempo) crea defensa en profundidad. Incluso si una clave privada y su frase de contraseña se ven comprometidas, un atacante no puede autenticarse sin el token TOTP.
Instale y configure libpam-google-authenticator en el servidor:
apt install libpam-google-authenticator
google-authenticator
Luego configure PAM y sshd_config:
# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Con AuthenticationMethods publickey,keyboard-interactive, un usuario debe proporcionar una clave válida Y un código TOTP. Esta es la configuración de producción correcta para servidores de alto valor.
Autoridad de certificación SSH: Escalado de la gestión de claves
En entornos con docenas de servidores y múltiples administradores, gestionar entradas individuales de authorized_keys se vuelve operativamente insostenible. Los certificados SSH resuelven esto.
Una Autoridad de Certificación (CA) SSH firma claves de usuario y host. Los servidores confían en la clave pública de la CA en lugar de en las claves de usuario individuales. Agregar un nuevo administrador solo requiere firmar su clave pública — sin cambios en el archivo authorized_keys de ningún servidor.
# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub
En cada servidor, configure la confianza para la CA:
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub
Así es como la infraestructura a gran escala (incluidos los proveedores de nube y las empresas) gestiona el acceso SSH sin gestión de claves por servidor.
Matriz de decisión práctica: Configuración SSH por caso de uso



Caso de uso
Tipo de clave
Puerto
Autenticación por contraseña
Inicio de sesión root
Reenvío
MFA








—
—
—
—
—
—
—








VPS personal
Ed25519
2222+
Deshabilitada
Prohibido
Deshabilitado
Opcional








Servidor web de producción
Ed25519
No predeterminado
Deshabilitada
No
Deshabilitado
Requerido








Bastión / host de salto
Ed25519
22 o personalizado
Deshabilitada
No
Controlado
Requerido








Automatización CI/CD
Ed25519 (clave de implementación)
No predeterminado
Deshabilitada
No
Deshabilitado
No (solo clave)








Servidor de base de datos
Ed25519
No predeterminado
Deshabilitada
No
Solo local
Requerido








Servidor de desarrollo
Ed25519
Predeterminado o personalizado
Opcional
No
Opcional
Opcional





Configuración de SSH en la infraestructura de AlexHost
Cuando aprovisiona un VPS o un servidor dedicado a través de AlexHost, el acceso SSH está configurado de forma predeterminada. La contraseña root inicial se entrega a través del correo electrónico de aprovisionamiento, y la primera acción recomendada es:

Iniciar sesión como root, crear un usuario administrativo no root y agregar su clave pública al ~/.ssh/authorized_keys de ese usuario.
Aplicar la línea base de refuerzo de sshd_config documentada anteriormente.
Deshabilitar la autenticación por contraseña y el inicio de sesión root.
Configurar su firewall para restringir el acceso SSH a rangos de IP conocidos donde sea operativamente factible.

Si prefiere una capa de gestión gráfica junto con SSH, las opciones de VPS con cPanel y Paneles de control VPS de AlexHost proporcionan una interfaz web para tareas comunes mientras dejan SSH disponible para el control administrativo completo.
Para entornos donde necesita asegurar aplicaciones web que se ejecutan en el mismo servidor, combinar el refuerzo SSH con un certificado SSL correctamente configurado cubre tanto las capas de transporte administrativo como de aplicación.
Lista de verificación de puntos clave técnicos
Antes de considerar su configuración SSH lista para producción, verifique cada uno de los siguientes puntos:
Gestión de claves

Las claves privadas usan Ed25519 o RSA-4096 como mínimo
Todas las claves privadas están protegidas con una frase de contraseña sólida
El directorio ~/.ssh/ tiene permisos 700; authorized_keys tiene 600

• Las claves de implementación usan las opciones restrict y command= donde corresponda
• El programa de rotación de claves está documentado y aplicado

Configuración del servidor

PasswordAuthentication no está configurado y activo
PermitRootLogin no o prohibit-password está aplicado
SSH se ejecuta en un puerto no predeterminado con las reglas del firewall actualizadas
AllowUsers o AllowGroups restringe el acceso a cuentas nombradas
LoginGraceTime está configurado en 30 segundos o menos
sshd -t pasa sin errores después de cada cambio de configuración

Refuerzo criptográfico

KexAlgorithms excluye diffie-hellman-group1-sha1 y diffie-hellman-group14-sha1

• Ciphers excluye 3des-cbc, arcfour y blowfish-cbc
• MACs usa solo variantes -etm (cifrar-luego-MAC)

Seguridad operativa

• Los registros de autenticación SSH son monitoreados (/var/log/auth.log o journalctl -u sshd)
• fail2ban o equivalente está configurado para bloquear fallos de autenticación repetidos
• Las huellas digitales de las claves de host están registradas y almacenadas fuera de banda para verificación
• MFA está habilitado para todas las sesiones de usuario interactivas en sistemas de producción
• La CA SSH está en uso para entornos con más de cinco servidores o tres administradores

Preguntas frecuentes

¿Cuál es la diferencia entre claves SSH y certificados SSH?

Las claves SSH requieren que cada servidor almacene la clave pública del usuario en authorized_keys. Los certificados SSH están firmados por una Autoridad de Certificación; los servidores confían en la CA en lugar de en las claves individuales. Los certificados escalan a grandes flotas sin gestión de claves por servidor y admiten tiempos de vencimiento, lo que hace que la revocación sea sencilla.

¿Por qué aparece Permission denied (publickey) incluso cuando la clave es correcta?

Las causas más comunes son permisos de archivo incorrectos en ~/.ssh/ (debe ser 700) o authorized_keys (debe ser 600), un directorio home con permisos de escritura para todos (bloqueado por StrictModes), o una directiva AllowUsers en sshd_config que excluye la cuenta que se conecta. Verifique journalctl -u sshd en el servidor para conocer el motivo específico del rechazo.

¿Cambiar el puerto SSH del 22 es una medida de seguridad real?

Elimina los ataques oportunistas automatizados dirigidos al puerto 22, lo que reduce significativamente el ruido de los registros y los intentos de autenticación fallidos. No protege contra un atacante dirigido que realiza un escaneo de puertos. Debe combinarse con fail2ban, autenticación solo con clave y lista de permitidos de IP en el firewall para una mejora de seguridad significativa.

¿Puedo usar SSH sin una dirección IP estática en el lado del cliente?

Sí. La autenticación basada en claves no requiere una IP de cliente fija. Si desea restringir por IP, use la opción from= en authorized_keys o reglas de firewall. Para IPs dinámicas, considere usar una VPN para establecer una identidad de red estable antes de conectarse, en lugar de abrir SSH a todo internet.

¿Cuál es la forma más segura de recuperar el acceso SSH si estoy bloqueado?

Acceda al servidor a través de la consola fuera de banda de su proveedor de alojamiento (VNC, IPMI o KVM over IP). Desde allí, monte el sistema de archivos, corrija el problema de sshd_config o authorized_keys y reinicie el daemon SSH. En los planes de VPS y servidor dedicado de AlexHost, la consola del proveedor está disponible a través del portal del cliente y no depende de que SSH esté funcionando.