Administración remota de servidores: SSH, DNS, FTP y redes

La administración remota de servidores es el conjunto de técnicas, protocolos y herramientas que permiten gestionar un servidor Linux desde cualquier lugar del mundo sin acceso físico al hardware. Los pilares de esta administración son cuatro: SSH (Secure Shell), el protocolo estándar para acceder a la línea de comandos del servidor de forma segura; DNS (Domain Name System), el sistema que traduce nombres de dominio en direcciones IP; FTP/SFTP, los protocolos para transferir archivos entre cliente y servidor; y las herramientas de diagnóstico de red como traceroute y el archivo hosts. Dominar estas herramientas es imprescindible para cualquier administrador de sistemas o propietario de servidor.

Por qué la administración remota es fundamental en 2026

En 2026, prácticamente ningún servidor web moderno está gestionado de forma local: los servidores están en centros de datos distribuidos geográficamente, en infraestructuras cloud o en instalaciones de hosting compartido. El administrador de sistemas trabaja remotamente desde su oficina, desde casa o desde cualquier lugar con conexión a internet.

Esta realidad hace que las herramientas de administración remota sean tan importantes como el propio servidor. Un administrador que no domina SSH, que no entiende cómo funciona el DNS, o que no sabe cómo transferir archivos de forma segura está significativamente limitado en su capacidad para gestionar y solucionar problemas en producción.

Los cuatro pilares de la administración remota de servidores cubren necesidades distintas pero complementarias:

SSH: el protocolo estándar de administración remota

SSH (Secure Shell) es un protocolo criptográfico diseñado para proporcionar acceso seguro a un servidor remoto a través de una red no segura. Fue creado en 1995 como sustituto de protocolos inseguros como Telnet y rsh, que transmitían todo el tráfico (incluyendo contraseñas) en texto plano. En 2026, SSH es el estándar de facto para la administración remota de servidores Linux y macOS.

Qué hace SSH diferente de Telnet

Cómo funciona SSH: autenticación por clave pública

SSH soporta dos métodos de autenticación principales. La autenticación por contraseña es sencilla pero vulnerable a ataques de fuerza bruta. La autenticación por clave pública es criptográficamente segura y es la recomendada para cualquier servidor en producción:

1. El administrador genera un par de claves criptográficas: una clave privada (que se queda en su equipo local, protegida y nunca se comparte) y una clave pública (que se instala en el servidor).
2. Cuando el administrador intenta conectarse, el servidor genera un desafío aleatorio y lo cifra con la clave pública del administrador.
3. Solo quien tenga la clave privada correspondiente puede descifrar ese desafío y responderlo correctamente.
4. El servidor verifica la respuesta y, si es correcta, concede acceso sin necesidad de transmitir ninguna contraseña por la red.

El algoritmo de clave recomendado en 2026 es Ed25519 (Edwards-curve Digital Signature Algorithm): más rápido, más pequeño y más seguro que RSA de 2048 bits.

# Generar un par de claves Ed25519 (recomendado en 2026):
ssh-keygen -t ed25519 -C "admin@tudominio.com"
# El sistema preguntará dónde guardar las claves (por defecto ~/.ssh/id_ed25519)
# y si quieres protegerlas con una passphrase (recomendado)

# La clave privada queda en: ~/.ssh/id_ed25519 (NUNCA compartir ni subir)
# La clave pública queda en: ~/.ssh/id_ed25519.pub (esta se instala en el servidor)

# Copiar la clave pública al servidor de forma automática:
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@ip-del-servidor

# O manualmente (añadir el contenido de id_ed25519.pub al servidor en):
# ~/.ssh/authorized_keys (un servidor por línea)

# Conectarse al servidor usando la clave:
ssh -i ~/.ssh/id_ed25519 usuario@ip-del-servidor
# o simplemente (si la clave está en la ruta por defecto):
ssh usuario@ip-del-servidor

Hardening de SSH: configuración segura del servidor

La configuración por defecto de SSH es funcional pero no óptima desde el punto de vista de la seguridad. Estas son las medidas de hardening más importantes, configuradas en /etc/ssh/sshd_config:

# /etc/ssh/sshd_config — configuración de seguridad recomendada:

# Desactivar el login como root (el atacante debería conocer el usuario además de la clave):
PermitRootLogin no

# Desactivar la autenticación por contraseña (solo permitir claves):
PasswordAuthentication no
ChallengeResponseAuthentication no

# Activar solo autenticación por clave pública:
PubkeyAuthentication yes

# Limitar los usuarios que pueden conectarse por SSH:
AllowUsers tuusuario deploy backup

# Cambiar el puerto por defecto (reduce el ruido en los logs, no es seguridad real):
Port 2222

# Limitar el número de intentos de autenticación:
MaxAuthTries 3

# Tiempo máximo para completar la autenticación:
LoginGraceTime 30

# Desactivar reenvío de X11 si no lo necesitas:
X11Forwarding no

# Aplicar los cambios (verificar primero que la config es correcta):
sudo sshd -t  # Verificar sintaxis sin reiniciar
sudo systemctl reload sshd  # Aplicar cambios sin cerrar sesiones activas

Importante: antes de desactivar la autenticación por contraseña y cerrar sesión, verifica desde otra terminal que puedes conectarte correctamente con la clave pública. Si cometes un error y te quedas sin acceso SSH, necesitarás acceso de emergencia al servidor (consola VNC/KVM en Plesk, o acceso físico al servidor).

El archivo ~/.ssh/config: simplifica tus conexiones habituales

# ~/.ssh/config — configuración de conexiones habituales:

# Servidor de producción:
Host prod
    HostName 195.234.56.78
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Servidor de staging:
Host staging
    HostName 195.234.56.79
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_staging

# Ahora puedes conectarte simplemente con:
ssh prod
ssh staging

# En lugar de:
ssh -i ~/.ssh/id_ed25519 -p 22 admin@195.234.56.78

DNS: el sistema de nombres de dominio

El DNS (Domain Name System) es la infraestructura que hace posible que uses nombres de dominio en lugar de direcciones IP. Es la "guía telefónica" de internet: cuando escribes sys4net.com en el navegador, el DNS lo traduce en la dirección IP del servidor que aloja ese sitio.

Cómo funciona la resolución DNS

La resolución de un nombre de dominio implica una jerarquía de servidores DNS que trabajan en cadena. El proceso completo para resolver sys4net.com desde cero:

1. Tu dispositivo consulta su caché DNS local. Si tiene la respuesta guardada y el TTL no ha expirado, la usa directamente.
2. Si no está en caché, consulta el resolver recursivo configurado en tu red (normalmente el del ISP, o uno público como 1.1.1.1 o 8.8.8.8).
3. El resolver consulta uno de los 13 servidores raíz (root servers, de la a a la m). El servidor raíz no sabe la IP de sys4net.com, pero sabe qué servidores gestionan el TLD .com.
4. El resolver consulta el servidor TLD de .com, que le dice qué servidores de nombres son autoritativos para sys4net.com.
5. El resolver consulta el servidor de nombres autoritativo de sys4net.com, que devuelve la IP final.
6. El resolver guarda la respuesta en caché según el TTL indicado y la devuelve a tu dispositivo.

Tipos de registros DNS: guía completa

Herramientas de diagnóstico DNS

# dig — la herramienta más potente para consultas DNS:

# Consultar el registro A de un dominio:
dig sys4net.com A

# Consultar un tipo específico de registro:
dig sys4net.com MX
dig sys4net.com TXT
dig sys4net.com NS
dig _dmarc.sys4net.com TXT

# Consultar un servidor DNS específico (para verificar propagación):
dig @1.1.1.1 sys4net.com A    # Cloudflare DNS
dig @8.8.8.8 sys4net.com A    # Google DNS
dig @ns1.sys4net.com sys4net.com A  # El propio servidor autoritativo

# Salida corta (solo el valor del registro):
dig +short sys4net.com A

# Traza completa del proceso de resolución (muestra todos los saltos):
dig +trace sys4net.com A

# nslookup — alternativa más sencilla disponible en Windows, Linux y macOS:
nslookup sys4net.com
nslookup -type=MX sys4net.com
nslookup -type=TXT sys4net.com

# host — la más simple de las tres:
host sys4net.com
host -t MX sys4net.com

El TTL (Time To Live) del DNS: por qué importa

El TTL es el tiempo en segundos que los resolvers DNS pueden guardar en caché una respuesta. Tiene implicaciones directas en la velocidad de propagación de los cambios DNS:

Buena práctica para migraciones: reduce el TTL de los registros DNS críticos (A, MX) a 300 segundos o menos al menos 24 horas antes de una migración planificada. Así, cuando hagas el cambio, se propagará en minutos en lugar de horas. Una vez completada la migración y verificado que todo funciona, vuelve a aumentar el TTL a su valor normal.

FTP y SFTP: transferencia de archivos al servidor

Transferir archivos entre tu equipo local y el servidor es una tarea cotidiana en la administración de servidores: subir actualizaciones de código, descargar logs para análisis, subir copias de seguridad, descargar archivos de configuración para editarlos localmente. Hay tres protocolos principales para esto, con diferencias importantes de seguridad:

FTP: el protocolo original, inseguro por diseño

FTP (File Transfer Protocol, RFC 959, 1985) fue diseñado en una época en que internet era una red académica cerrada y la seguridad no era una preocupación. Transmite todo en texto plano: el nombre de usuario, la contraseña y el contenido de todos los archivos transferidos son legibles por cualquier persona que intercepte el tráfico de red. En 2026, FTP puro no debería usarse nunca en internet para transferir archivos de producción.

FTP usa además una arquitectura de doble canal que complica los firewalls:

• Canal de control: puerto 21, para comandos y respuestas del servidor.
• Canal de datos: puerto 20 (modo activo) o un puerto aleatorio mayor de 1024 (modo pasivo), para la transferencia real de datos.

SFTP: transferencia segura sobre SSH

SFTP (SSH File Transfer Protocol) no tiene nada que ver con FTP a pesar de su nombre similar. Es un protocolo completamente independiente que se ejecuta sobre el canal SSH, aprovechando el cifrado y la autenticación de SSH para transferir archivos de forma segura. Usa el puerto 22 (el mismo que SSH) y la misma autenticación (usuario/contraseña o clave pública).

FTPS: FTP sobre TLS

FTPS es FTP con cifrado TLS añadido. Hay dos variantes: FTPS implícito (puerto 990, TLS desde el inicio) y FTPS explícito (puerto 21 con STARTTLS). A diferencia de SFTP, sí mantiene la arquitectura de doble canal de FTP, lo que sigue complicando los firewalls.

Uso de SFTP desde la línea de comandos

# Conectar a un servidor por SFTP:
sftp usuario@ip-del-servidor
sftp -P 2222 usuario@ip-del-servidor  # Puerto personalizado

# Comandos dentro de la sesión SFTP:
ls          # Listar archivos en el servidor (remoto)
lls         # Listar archivos locales
pwd         # Directorio actual en el servidor
lpwd        # Directorio actual local
cd /ruta/   # Cambiar directorio en el servidor
lcd /ruta/  # Cambiar directorio local

# Descargar archivos del servidor:
get archivo.txt              # Descargar un archivo
get -r carpeta/              # Descargar directorio completo (recursivo)
mget *.log                   # Descargar múltiples archivos con comodín

# Subir archivos al servidor:
put archivo.txt              # Subir un archivo
put -r carpeta/              # Subir directorio completo
mput *.php                   # Subir múltiples archivos

# Salir:
bye
exit

Clientes SFTP gráficos

Para quienes prefieren una interfaz gráfica, estos son los clientes SFTP más usados en 2026:

IPv4 e IPv6: las direcciones de internet

Cada dispositivo conectado a internet necesita una dirección IP para poder comunicarse. En 2026 coexisten dos versiones del protocolo IP, con características y propósitos distintos:

IPv4: el estándar histórico, prácticamente agotado

IPv4 usa direcciones de 32 bits representadas como cuatro grupos de números decimales separados por puntos (por ejemplo, 195.234.56.78). Con 32 bits, el espacio de direcciones es de 2³² = 4.294.967.296 direcciones únicas, aproximadamente 4.300 millones. En los años 80, cuando se diseñó IPv4, nadie imaginaba que existirían más de 4.000 millones de dispositivos conectados a internet.

El espacio de direcciones IPv4 públicas se agotó oficialmente en 2011 (IANA) y en 2019 (RIPE NCC para Europa). La solución temporal fue NAT (Network Address Translation): múltiples dispositivos privados comparten una única IP pública a través del router. NAT funciona pero introduce complejidad y limita ciertas funcionalidades de red.

IPv6: el futuro, con espacio prácticamente ilimitado

IPv6 usa direcciones de 128 bits representadas como ocho grupos de cuatro dígitos hexadecimales separados por dos puntos (por ejemplo, 2001:0db8:85a3:0000:0000:8a2e:0370:7334, que se puede abreviar como 2001:db8:85a3::8a2e:370:7334). Con 128 bits, el espacio de direcciones es de 2¹²⁸ = 340 undecillones de direcciones, un número tan grande que es prácticamente ilimitado para cualquier escenario imaginable.

# Verificar la conectividad IPv4 e IPv6 del servidor:
# IPv4:
ping -4 google.com
curl -4 https://ifconfig.me  # Ver la IP pública IPv4 del servidor

# IPv6:
ping6 google.com
curl -6 https://ifconfig.me  # Ver la IP pública IPv6 del servidor

# Ver todas las interfaces de red y sus IPs:
ip addr show
# o en sistemas más antiguos:
ifconfig -a

# Ver la tabla de rutas:
ip route show       # IPv4
ip -6 route show    # IPv6

# Verificar si el sitio web responde sobre IPv6:
curl -6 -I https://sys4net.com

Traceroute: diagnosticar problemas de red

Traceroute es una herramienta de diagnóstico de red que muestra la ruta que siguen los paquetes desde tu equipo hasta un destino, identificando cada router (hop) intermedio y la latencia de cada salto. Es la herramienta estándar para diagnosticar dónde ocurre un problema de conectividad o latencia alta entre dos puntos de internet.

# Uso básico de traceroute:
# Linux y macOS:
traceroute sys4net.com

# Windows:
tracert sys4net.com

# Con IPv6:
traceroute6 sys4net.com  # Linux
tracert -6 sys4net.com   # Windows

# Especificar el número máximo de saltos (por defecto 30):
traceroute -m 20 sys4net.com

# Usar ICMP en lugar de UDP (a veces da mejores resultados):
traceroute -I sys4net.com  # Linux
# Windows usa ICMP por defecto

# Salida típica de traceroute:
# traceroute to sys4net.com (195.234.56.78), 30 hops max, 60 byte packets
#  1  router.local (192.168.1.1)        1.2 ms   0.9 ms   1.0 ms
#  2  10.10.1.1                         5.3 ms   5.1 ms   5.4 ms
#  3  * * *
#  4  mad-bb1.proveedor.com (83.34.1.1) 12.1 ms  11.9 ms  12.2 ms
#  5  sys4net.com (195.234.56.78)       12.5 ms  12.3 ms  12.4 ms

Cómo interpretar la salida de traceroute

El archivo hosts: sobreescribir el DNS localmente

El archivo hosts es un archivo del sistema operativo que mapea nombres de dominio a direcciones IP de forma local, con prioridad sobre el DNS. Cuando el sistema operativo necesita resolver un nombre de dominio, consulta primero el archivo hosts antes de hacer ninguna consulta DNS: si el nombre aparece en el archivo hosts, usa esa IP directamente sin consultar ningún servidor DNS.

Ubicación del archivo hosts según el sistema operativo

Formato del archivo hosts y usos prácticos

# Formato: IP_destino  nombre_de_dominio  [alias_opcional]
# Las líneas que empiezan con # son comentarios

# Entradas por defecto (no modificar):
127.0.0.1   localhost
::1         localhost ip6-localhost ip6-loopback

# Caso de uso 1: probar un sitio en el nuevo servidor antes de cambiar el DNS
# Apunta el dominio a la IP del nuevo servidor solo en tu equipo:
195.234.56.79   tudominio.com
195.234.56.79   www.tudominio.com
# Solo TÚ verás el sitio en el nuevo servidor; el resto del mundo sigue en el antiguo

# Caso de uso 2: bloquear dominios no deseados (publicidad, malware):
0.0.0.0   ads.ejemplo.com
0.0.0.0   tracking.ejemplo.com
# La IP 0.0.0.0 hace que el dominio no resuelva a ningún lugar

# Caso de uso 3: simular un entorno de producción en local:
127.0.0.1   api.miapp.local
127.0.0.1   admin.miapp.local

# Vaciar la caché DNS después de modificar el archivo hosts:
# macOS:
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Windows:
ipconfig /flushdns
# Linux:
sudo systemd-resolve --flush-caches
# o:
sudo resolvectl flush-caches

Puertos de red más importantes en administración de servidores

Preguntas frecuentes sobre administración remota de servidores

¿Es seguro usar SSH con contraseña en lugar de clave pública?

La autenticación SSH por contraseña es funcional pero significativamente menos segura que la autenticación por clave pública. Los servidores expuestos a internet reciben cientos o miles de intentos de acceso por fuerza bruta cada día contra el puerto SSH. Con una contraseña, la seguridad depende de su complejidad y de que no haya sido filtrada en ninguna brecha de datos. Con autenticación por clave pública y PasswordAuthentication desactivado, los ataques de fuerza bruta son matemáticamente inviables: no hay ninguna contraseña que adivinar. En producción, la autenticación por clave pública con PasswordAuthentication desactivado es obligatoria.

¿Cuánto tarda en propagarse un cambio de DNS?

Depende del TTL configurado en el registro DNS antes del cambio. Si el TTL era de 86.400 segundos (24 horas), los resolvers DNS que tenían el registro en caché pueden tardar hasta 24-48 horas en actualizar su caché y ver el nuevo valor. Si el TTL era de 300 segundos (5 minutos), el cambio se propaga en 5-10 minutos. La buena práctica es reducir el TTL a 300 segundos o menos al menos 24 horas antes de un cambio planificado, y volver a aumentarlo una vez completado el cambio.

¿Cuál es la diferencia entre SFTP y SCP?

Ambos son protocolos de transferencia de archivos que funcionan sobre SSH y usan el mismo cifrado y autenticación. SCP (Secure Copy Protocol) es el más antiguo y sencillo: solo copia archivos y directorios de un lugar a otro sin posibilidad de listar directorios, pausar transferencias o reanudar copias interrumpidas. SFTP (SSH File Transfer Protocol) es un protocolo completo de gestión de archivos remotos: permite listar directorios, renombrar, eliminar, cambiar permisos, reanudar transferencias interrumpidas y mucho más. En 2026 se recomienda SFTP sobre SCP para la mayoría de los usos; SCP está técnicamente deprecado en algunas distribuciones de OpenSSH.

¿Por qué mi sitio web no se ve en el nuevo servidor aunque cambié el DNS?

Lo más probable es que tu caché DNS local o la caché del resolver DNS que usa tu dispositivo todavía tiene la IP antigua. Los cambios de DNS no son instantáneos: pueden tardar entre minutos y 48 horas en propagarse según el TTL configurado. Para ver el sitio en el nuevo servidor inmediatamente (solo en tu equipo), usa el archivo hosts para apuntar el dominio directamente a la IP del nuevo servidor. Para verificar que el DNS ya apunta al nuevo servidor desde distintos puntos del mundo, usa herramientas como whatsmydns.net.

¿Es mejor IPv4 o IPv6 para un servidor web?

Lo ideal en 2026 es tener ambos simultáneamente (configuración dual-stack). IPv4 sigue siendo dominante y necesario para garantizar compatibilidad con todos los usuarios. IPv6 es el futuro y ya representa un porcentaje significativo del tráfico de internet. Con dual-stack, los clientes con IPv6 se conectan por IPv6 (generalmente más directo, sin NAT) y los que solo tienen IPv4 se conectan por IPv4. Los servidores de sys4net soportan dual-stack por defecto en todos los planes.

¿Para qué sirve el archivo hosts y cuándo debo usarlo?

El archivo hosts permite redirigir un dominio a una IP específica solo en tu equipo, sobreescribiendo el DNS global. Los usos más prácticos son: probar que un sitio web funciona correctamente en un nuevo servidor antes de cambiar el DNS globalmente (solo tú ves el nuevo servidor, el resto del mundo sigue viendo el antiguo); bloquear dominios de publicidad o malware dirigiéndolos a 0.0.0.0; y simular un entorno de producción en local usando nombres de dominio en lugar de localhost. Recuerda vaciar la caché DNS del sistema después de modificar el archivo hosts para que los cambios surtan efecto inmediatamente.