Qué es SSH y para qué sirve: guía completa

SSH (Secure Shell) es un protocolo de red criptográfico que proporciona acceso remoto seguro a un servidor a través de una red no segura como internet. Permite ejecutar comandos en un servidor remoto como si estuvieras físicamente delante de él, con toda la comunicación cifrada de extremo a extremo. Funciona en el puerto 22 por defecto y usa criptografía asimétrica (clave pública y privada) para autenticar tanto al servidor como al cliente. En 2026, SSH es el estándar universal para la administración remota de servidores Linux, macOS y cualquier sistema Unix-like, y también la base de protocolos como SFTP y SCP para transferencia de archivos.

La historia de SSH: por qué nació y qué reemplazó

Para entender el valor de SSH es imprescindible entender el contexto en el que surgió. Antes de SSH, los administradores de sistemas usaban protocolos como Telnet, rlogin y rsh para acceder remotamente a los servidores. Todos estos protocolos transmitían absolutamente toda la comunicación en texto plano, incluyendo las contraseñas. En la red universitaria y de investigación de los años 80 y principios de los 90, esto no era percibido como un problema grave porque las redes eran cerradas y los usuarios eran investigadores de confianza.

En febrero de 1995, un ataque a la red de la Universidad de Helsinki capturó miles de contraseñas interceptando el tráfico de Telnet y rlogin en texto plano. Tatu Ylönen, un investigador de la universidad afectada, diseñó SSH como respuesta directa a ese ataque y publicó la primera versión de forma gratuita en julio de 1995. La adopción fue inmediata y masiva: en pocos meses, decenas de miles de administradores de sistemas en todo el mundo habían instalado SSH.

En 2006, el IETF estandarizó SSH-2 (la versión actual, con mejoras significativas de seguridad sobre SSH-1) mediante el RFC 4251. OpenSSH, la implementación de código abierto de SSH-2 creada por el proyecto OpenBSD, es hoy la implementación más usada del mundo y viene preinstalada en prácticamente todas las distribuciones de Linux y en macOS.

Qué hace SSH exactamente: los tres componentes

SSH no es solo un protocolo de terminal remoto. Es un protocolo de seguridad de propósito general que proporciona tres funciones fundamentales que se aplican a todo lo que se transmite a través del canal SSH:

Cómo funciona SSH: el handshake y el cifrado

Cuando ejecutas ssh usuario@servidor.com, ocurre el siguiente proceso antes de que veas el prompt del servidor:

Fase 1: Negociación de la versión y el algoritmo

El cliente y el servidor intercambian sus versiones de SSH soportadas y negocian los algoritmos a usar para el cifrado de la sesión, el intercambio de claves y los códigos de autenticación de mensajes. Ambas partes eligen los algoritmos más seguros que ambos soportan.

Fase 2: Intercambio de claves (Key Exchange)

Usando el algoritmo Diffie-Hellman o su variante ECDH (Elliptic Curve Diffie-Hellman), el cliente y el servidor generan una clave de sesión compartida y temporal sin necesidad de transmitirla por la red. Este proceso es matemáticamente elegante: ambas partes generan la misma clave de sesión partiendo de información pública, pero es computacionalmente imposible para un observador externo derivar esa clave, aunque haya interceptado toda la negociación.

Fase 3: Verificación del servidor (Server Authentication)

El servidor envía su clave pública de host al cliente. Si es la primera vez que el cliente se conecta a ese servidor, SSH pregunta al administrador si confía en esa clave. Si el cliente ya se conectó anteriormente, compara la clave recibida con la guardada en ~/.ssh/known_hosts. Si no coincide, SSH muestra una advertencia de seguridad grave porque puede ser un ataque man-in-the-middle.

# La primera vez que te conectas a un servidor nuevo, SSH muestra:
# The authenticity of host 'servidor.com (195.234.56.78)' can't be established.
# ED25519 key fingerprint is SHA256:abc123def456...
# Are you sure you want to continue connecting (yes/no/[fingerprint])?

# Verificar el fingerprint ANTES de aceptar (en el servidor, como root):
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# Compara el resultado con el fingerprint que te muestra el cliente

# Ver las claves de host guardadas (para no volver a preguntar):
cat ~/.ssh/known_hosts

Fase 4: Autenticación del cliente (Client Authentication)

Una vez verificado el servidor, el cliente debe probar su identidad al servidor. SSH soporta varios métodos de autenticación, por orden de seguridad:

Fase 5: Apertura del canal seguro

Una vez autenticadas ambas partes, SSH establece uno o varios canales lógicos multiplexados sobre la conexión cifrada. Cada canal puede transportar una sesión de terminal, una transferencia de archivo SFTP, un túnel de red o cualquier otra funcionalidad de SSH. La multiplexación permite que múltiples operaciones simultáneas compartan la misma conexión TCP cifrada.

Para qué sirve SSH: más allá del terminal remoto

La mayoría de los administradores piensa en SSH principalmente como una forma de abrir un terminal remoto en un servidor. Pero SSH es mucho más versátil:

1. Acceso a terminal remoto (el uso más conocido)

# Conectarse a un servidor por SSH:
ssh usuario@servidor.com
ssh usuario@195.234.56.78
ssh -p 2222 usuario@servidor.com  # Puerto personalizado

# Ejecutar un solo comando sin abrir sesión interactiva:
ssh usuario@servidor.com 'df -h'
ssh usuario@servidor.com 'sudo systemctl restart nginx'
ssh usuario@servidor.com 'tail -100 /var/log/nginx/error.log'

# Conectarse con una clave específica:
ssh -i ~/.ssh/id_ed25519 usuario@servidor.com

2. Transferencia de archivos (SFTP y SCP)

SFTP (SSH File Transfer Protocol) y SCP (Secure Copy) son protocolos de transferencia de archivos que se ejecutan sobre el canal SSH, heredando su cifrado y autenticación automáticamente:

# Copiar un archivo local al servidor con SCP:
scp archivo.txt usuario@servidor.com:/ruta/destino/

# Copiar un archivo del servidor a local:
scp usuario@servidor.com:/var/log/nginx/error.log ./logs/

# Copiar un directorio completo (recursivo):
scp -r ./mi-proyecto/ usuario@servidor.com:/var/www/html/

# Abrir una sesión SFTP interactiva:
sftp usuario@servidor.com

# Transferencia con barra de progreso y compresión:
scp -C archivo-grande.zip usuario@servidor.com:/destino/

3. Túneles SSH: reenvío de puertos

Los túneles SSH son una de las funcionalidades menos conocidas y más poderosas. Permiten reenviar tráfico de red a través del canal cifrado de SSH, creando conexiones seguras a servicios que de otra forma serían inaccesibles o inseguros:

# Túnel local (Local Port Forwarding):
# Reenvía el puerto local 8080 al puerto 80 del servidor remoto
# Útil para acceder a servicios internos del servidor (phpMyAdmin, panel admin) de forma segura
ssh -L 8080:localhost:80 usuario@servidor.com
# Ahora http://localhost:8080 en tu navegador local accede al puerto 80 del servidor

# Ejemplo práctico: acceder a phpMyAdmin sin exponerlo a internet:
ssh -L 8888:localhost:80 usuario@servidor.com
# Visita http://localhost:8888/phpmyadmin en tu navegador

# Acceder a MySQL directamente desde tu herramienta local (TablePlus, DBeaver, etc.):
ssh -L 3307:localhost:3306 usuario@servidor.com
# Conecta tu cliente MySQL a localhost:3307

# Túnel remoto (Remote Port Forwarding):
# Expone un puerto local de tu máquina en el servidor remoto
# Útil para mostrar un servidor de desarrollo local a alguien externo
ssh -R 9090:localhost:3000 usuario@servidor.com
# El puerto 9090 del servidor ahora apunta al puerto 3000 de tu máquina local

# Túnel dinámico (SOCKS proxy):
# Convierte SSH en un proxy SOCKS5 para todo el tráfico web
ssh -D 1080 usuario@servidor.com
# Configura tu navegador para usar SOCKS5 en localhost:1080

4. Git sobre SSH

Git usa SSH para autenticar y cifrar las operaciones con repositorios remotos. GitHub, GitLab, Bitbucket y cualquier servidor Git privado soportan autenticación por clave SSH, que es más segura y cómoda que la autenticación por contraseña HTTPS (que requiere introducir las credenciales en cada operación o usar un credential manager):

# Configurar Git para usar SSH con GitHub:
# 1. Genera una clave SSH específica para Git (o usa la que ya tienes):
ssh-keygen -t ed25519 -C "tu@email.com" -f ~/.ssh/id_ed25519_github

# 2. Añade la clave pública a tu cuenta de GitHub:
# GitHub > Settings > SSH and GPG keys > New SSH key
cat ~/.ssh/id_ed25519_github.pub
# Copia el contenido y pégalo en GitHub

# 3. Configura ~/.ssh/config para usar esa clave con GitHub:
# Host github.com
#     HostName github.com
#     User git
#     IdentityFile ~/.ssh/id_ed25519_github

# 4. Verifica la conexión:
ssh -T git@github.com
# Debe mostrar: Hi usuario! You've successfully authenticated...

# 5. Usa URLs SSH en lugar de HTTPS para los repositorios:
git clone git@github.com:usuario/repositorio.git
# En lugar de:
# git clone https://github.com/usuario/repositorio.git

# Cambiar un repositorio existente de HTTPS a SSH:
git remote set-url origin git@github.com:usuario/repositorio.git

5. Automatización y scripts

SSH es la base de prácticamente todos los sistemas de despliegue y automatización de servidores: Ansible, Fabric, Capistrano, las GitHub Actions con self-hosted runners, los pipelines de CI/CD que despliegan en servidores propios.

# Ejecutar un script local en el servidor remoto (sin copiarlo primero):
ssh usuario@servidor.com 'bash -s' < script-local.sh

# Ejecutar múltiples comandos en secuencia:
ssh usuario@servidor.com << 'EOF'
cd /var/www/html/mi-sitio
git pull origin main
composer install --no-dev
php artisan migrate --force
php artisan config:cache
sudo systemctl reload php8.2-fpm
EOF

# Script de despliegue básico con SSH:
#!/bin/bash
SERVIDOR="usuario@servidor.com"
RUTA="/var/www/html/mi-sitio"

echo "Desplegando en producción..."
ssh $SERVIDOR "cd $RUTA && git pull && composer install --no-dev && php artisan migrate --force"
echo "Despliegue completado."

6. X11 Forwarding: aplicaciones gráficas remotas

# SSH puede reenviar aplicaciones gráficas X11 del servidor a tu pantalla local:
# (Requiere un servidor X11 en el cliente: Xming en Windows, XQuartz en macOS)
ssh -X usuario@servidor.com

# Dentro de la sesión SSH con X11 forwarding:
gedit archivo.txt    # El editor se abre en tu pantalla local
firefox              # El navegador del servidor se muestra en tu pantalla

SSH vs Telnet vs RDP: cuándo usar cada protocolo

Autenticación por clave pública: el método más seguro

La autenticación por clave pública es la forma recomendada de autenticarse en SSH en cualquier servidor de producción. Elimina la vulnerabilidad de las contraseñas frente a ataques de fuerza bruta y hace prácticamente imposible el acceso no autorizado incluso si un atacante tiene acceso ilimitado de intentos.

Cómo funciona la autenticación por clave pública

1. El administrador genera un par de claves: una clave privada (que permanece en su equipo local, cifrada con una passphrase) y una clave pública (que se instala en el servidor en el archivo ~/.ssh/authorized_keys).
2. Cuando el cliente intenta conectarse, el servidor genera un número aleatorio, lo cifra con la clave pública del cliente y envía el resultado al cliente.
3. Solo quien tenga la clave privada correspondiente puede descifrar ese mensaje. El cliente descifra, combina el resultado con el identificador de sesión y genera una firma criptográfica que envía al servidor.
4. El servidor verifica la firma usando la clave pública. Si la verificación es exitosa, la identidad del cliente queda demostrada sin que la clave privada haya salido nunca del equipo del cliente.

Algoritmos de clave SSH y cuál usar en 2026

# Generar clave Ed25519 (recomendado):
ssh-keygen -t ed25519 -C "admin-servidor-produccion"
# -t: tipo de algoritmo
# -C: comentario (útil para identificar para qué servidor o cuenta es la clave)
# Acepta la ruta por defecto (~/.ssh/id_ed25519) o especifica una propia
# Introduce una passphrase fuerte (protege la clave privada si alguien roba el archivo)

# Generar RSA 4096 bits (para compatibilidad con sistemas antiguos):
ssh-keygen -t rsa -b 4096 -C "admin-servidor-legacy"

# Ver la huella digital de una clave pública:
ssh-keygen -lf ~/.ssh/id_ed25519.pub
# Muestra el número de bits, el fingerprint SHA256, el comentario y el tipo

# Ver el contenido de la clave pública (para copiarla al servidor):
cat ~/.ssh/id_ed25519.pub
# Resultado: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... admin-servidor-produccion

Instalar la clave pública en el servidor

# Método 1: ssh-copy-id (automático, recomendado):
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@servidor.com
# Esto añade la clave pública al archivo ~/.ssh/authorized_keys del usuario en el servidor

# Método 2: manual (cuando no tienes acceso directo aún):
# Copia el contenido de tu clave pública:
cat ~/.ssh/id_ed25519.pub
# Conéctate al servidor y añade la clave:
ssh usuario@servidor.com
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "CLAVE_PUBLICA_AQUI" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Verificar que la autenticación por clave funciona antes de desactivar la contraseña:
# Abre UNA NUEVA TERMINAL y prueba la conexión con la clave:
ssh -i ~/.ssh/id_ed25519 usuario@servidor.com
# Si funciona, ahora puedes desactivar la autenticación por contraseña en el servidor

Configuración segura de SSH en el servidor: sshd_config

El archivo /etc/ssh/sshd_config controla el comportamiento del servidor SSH (sshd). Una configuración segura es imprescindible para cualquier servidor expuesto a internet:

# /etc/ssh/sshd_config — configuración de producción recomendada en 2026:

# Puerto (cambiarlo reduce el ruido de bots en los logs, no es seguridad real):
Port 22

# Solo soportar SSH versión 2 (SSH-1 es obsoleto e inseguro):
# (En OpenSSH moderno, SSH-1 ya está eliminado por defecto)

# No permitir login directo como root:
PermitRootLogin no
# Si necesitas acceso root, conecta como usuario normal y usa sudo

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

# Solo permitir autenticación por clave pública:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Desactivar autenticación vacía o sin contraseña:
PermitEmptyPasswords no

# Limitar los intentos de autenticación:
MaxAuthTries 3

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

# Limitar los usuarios que pueden conectarse (whitelist):
AllowUsers tuusuario deployer backup-user

# Desactivar reenvío de agente SSH si no lo necesitas:
AllowAgentForwarding no

# Desactivar reenvío TCP si no usas túneles SSH:
AllowTcpForwarding no
# (Cambia a yes si necesitas túneles SSH)

# Desactivar X11 si no lo necesitas:
X11Forwarding no

# Mantener viva la conexión (útil para sesiones largas):
ClientAliveInterval 300    # El servidor envía un keepalive cada 5 minutos
ClientAliveCountMax 2      # Cierra la sesión si no hay respuesta en 2 intentos

# Desactivar la resolución DNS inversa (acelera las conexiones):
UseDNS no

# Algoritmos de cifrado seguros (eliminar los débiles):
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
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256

# Aplicar y verificar los cambios:
sudo sshd -t                  # Verificar sintaxis (sin reiniciar)
sudo systemctl reload sshd    # Aplicar sin cortar sesiones activas

Antes de desactivar PasswordAuthentication: abre una segunda sesión SSH en una terminal nueva y verifica que la autenticación por clave funciona correctamente. Si cometes un error y te quedas sin acceso, necesitarás la consola de emergencia del servidor (acceso VNC/KVM desde Plesk o el panel de control de tu proveedor de hosting).

El agente SSH: gestionar múltiples claves sin introducir la passphrase cada vez

Cuando proteges tu clave privada con una passphrase (como debe ser en producción), SSH te pedirá la passphrase cada vez que uses la clave. El agente SSH (ssh-agent) es un proceso que guarda las claves descifradas en memoria durante tu sesión, de forma que solo necesitas introducir la passphrase una vez por sesión:

# Iniciar el agente SSH (en muchos sistemas se inicia automáticamente):
eval "$(ssh-agent -s)"
# Resultado: Agent pid 12345

# Añadir tu clave al agente (te pedirá la passphrase una vez):
ssh-add ~/.ssh/id_ed25519
# Enter passphrase for ~/.ssh/id_ed25519: ****

# Ver las claves cargadas en el agente:
ssh-add -l
# 256 SHA256:abc123... admin-servidor-produccion (ED25519)

# En macOS, el sistema integra el agente SSH con el llavero (Keychain):
# Añadir la clave al llavero de macOS (no vuelve a pedir la passphrase):
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

# SSH Agent Forwarding: usar tu clave local en un servidor intermedio
# (para conectar desde el servidor A al servidor B sin copiar la clave privada al servidor A)
ssh -A usuario@servidor-a.com
# Dentro del servidor A, puedes conectarte al servidor B usando tu clave local:
ssh usuario@servidor-b.com

Diagnóstico de problemas SSH frecuentes

Permission denied (publickey)

# El servidor rechaza la autenticación por clave pública. Causas y soluciones:

# 1. La clave pública no está en authorized_keys del servidor:
cat ~/.ssh/authorized_keys  # Verificar en el servidor

# 2. Permisos incorrectos del directorio .ssh o authorized_keys:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# (El directorio .ssh debe ser propiedad del usuario, no de root)

# 3. El cliente no usa la clave correcta:
ssh -v usuario@servidor.com 2>&1 | grep "Offering\|Trying"
# Verás qué claves intenta el cliente

# 4. PasswordAuthentication desactivado y no tienes clave configurada:
# Necesitas acceso de emergencia (consola VNC/KVM) para activarlo temporalmente

# Modo verbose para diagnóstico detallado:
ssh -vvv usuario@servidor.com 2>&1 | head -50

Connection refused

# El servidor rechaza la conexión en el puerto 22. Causas:

# 1. SSH no está ejecutándose en el servidor:
sudo systemctl status sshd
sudo systemctl start sshd

# 2. El firewall bloquea el puerto 22:
sudo ufw status | grep 22
sudo ufw allow 22/tcp

# 3. SSH está configurado en un puerto diferente:
# Revisa el panel de control o usa un escáner de puertos:
nmap -p 1-65535 servidor.com | grep open

Host key verification failed

# El fingerprint del servidor ha cambiado (puede ser legítimo tras una reinstalación,
# o puede ser un ataque man-in-the-middle):

# Si el servidor fue reinstalado legitimamente:
# Eliminar la entrada antigua en known_hosts:
ssh-keygen -R servidor.com
# o:
ssh-keygen -R 195.234.56.78

# La próxima conexión te pedirá confirmar el nuevo fingerprint.
# Verifica el fingerprint con el proveedor del servidor antes de aceptarlo.

SSH en Plesk: acceso sin necesidad de configuración manual

En los servidores de sys4net con Plesk, el acceso SSH está disponible para todos los planes de servidor VPS y dedicado. Desde el panel de Plesk puedes:

• Ver las credenciales de acceso SSH desde Inicio > Acceso al servidor.
• Gestionar las claves SSH autorizadas desde Mi cuenta > Claves SSH.
• Acceder a una consola de emergencia (VNC) desde el panel del servidor en caso de pérdida de acceso SSH.
• Ver el log de accesos SSH en Herramientas y configuración > Registros del sistema.

Preguntas frecuentes sobre SSH

¿Es seguro tener el puerto SSH (22) abierto en internet?

Con la configuración correcta (autenticación por clave pública con PasswordAuthentication desactivado, PermitRootLogin no, MaxAuthTries 3), el puerto 22 expuesto a internet es seguro aunque reciba miles de intentos de acceso por fuerza bruta cada día. Los ataques de fuerza bruta son matemáticamente inviables contra claves Ed25519 o RSA-4096: tendrían que probar 2¹²⁸ combinaciones posibles, lo que con el hardware más potente existente llevaría más tiempo que la edad del universo. Cambiar el puerto de 22 a otro número reduce el ruido en los logs pero no añade seguridad real: los escáneres de puertos modernos encuentran SSH en cualquier puerto en segundos.

¿Qué diferencia hay entre SSH y HTTPS?

Ambos protocolos cifran la comunicación, pero tienen propósitos completamente distintos. SSH es un protocolo de administración de sistemas que proporciona acceso a la línea de comandos del servidor, transferencia de archivos y tunneling de red. HTTPS es un protocolo de navegación web que cifra la comunicación entre el navegador y el servidor web. SSH autentica al administrador que se conecta; HTTPS autentica al servidor web (mediante el certificado SSL). Aunque ambos usan criptografía asimétrica, lo hacen de formas distintas y para casos de uso completamente diferentes.

¿Puedo usar SSH desde Windows sin instalar nada?

Sí. Desde Windows 10 versión 1803 (2018) y Windows 11, OpenSSH está incluido como característica opcional del sistema. Puedes instalar el cliente OpenSSH desde Configuración > Aplicaciones > Características opcionales > Agregar una característica > Cliente OpenSSH. Una vez instalado, el comando ssh funciona exactamente igual que en Linux y macOS desde PowerShell o el símbolo del sistema. También están disponibles clientes gráficos como PuTTY (Windows), MobaXterm (Windows) y Termius (multiplataforma).

¿Cuál es la diferencia entre la clave SSH y la contraseña SSH?

Son dos métodos de autenticación distintos. La contraseña SSH es una contraseña del usuario del sistema operativo del servidor que se verifica en el servidor. La clave SSH es un par de archivos criptográficos (privado y público): el archivo privado está en tu equipo y nunca sale de él; el público está en el servidor. La autenticación por clave es más segura que la contraseña porque es matemáticamente imposible de forzar (a diferencia de las contraseñas, que pueden ser débiles o estar en diccionarios), y porque la clave privada nunca se transmite por la red. En producción, siempre deberías usar autenticación por clave y desactivar la autenticación por contraseña.

¿Qué es la passphrase de la clave SSH y por qué es importante?

La passphrase es una contraseña que protege el archivo de clave privada SSH en tu disco. Si alguien roba el archivo de clave privada (por ejemplo, comprometiendo tu ordenador), sin la passphrase no puede usarla. Con la passphrase, el archivo robado es inútil sin conocer también la passphrase. Es una segunda capa de seguridad: incluso si pierdes el archivo, el atacante no puede conectarse a tus servidores. El agente SSH (ssh-agent) permite que solo introduzcas la passphrase una vez por sesión, haciendo el uso diario tan cómodo como sin passphrase.

¿Cómo puedo compartir el acceso SSH a un servidor con otro administrador sin compartir mi clave privada?

Nunca compartas tu clave privada SSH. En cambio, pide al otro administrador que genere su propio par de claves y te envíe su clave pública (el archivo .pub, que es seguro compartir). Añade esa clave pública al archivo ~/.ssh/authorized_keys del servidor. Cada administrador tiene su propio par de claves y se autentica de forma independiente. Cuando un administrador ya no necesite acceso, eliminas su clave pública del authorized_keys sin afectar a los demás. Este modelo permite una gestión de accesos granular y auditable.