Qué es SSH: cómo funciona y para qué sirve

SSH (Secure Shell) es un protocolo de red que permite conectarse a otro equipo y trabajar en él —ejecutar comandos, mover archivos, abrir servicios— a través de una red en la que no confías, como Internet. Todo lo que viaja entre el cliente y el servidor va cifrado, y las dos partes se identifican antes de dejar pasar nada. Es el sustituto moderno de Telnet y de FTP, y desde hace años es el estándar de facto para administrar servidores por línea de comandos.

Mi tesis en este artículo es sencilla: SSH no es «una herramienta más de administración», es la pieza que hizo posible trabajar en máquinas remotas sin regalar las credenciales por el camino. Entender qué cifra, cómo autentica y para qué sirven las claves y los túneles convierte una caja negra en algo que se puede configurar con criterio, auditar y romper a propósito si hace falta. Y como casi todo lo que sostiene Internet, tiene detrás una historia curiosa y unos cuantos estándares que conviene saber nombrar.

Qué es SSH y por qué existe

SSH significa Secure Shell, «shell seguro». Su propósito original era uno muy concreto: sustituir a Telnet y a rlogin, que enviaban la contraseña del usuario y el resto de la sesión en texto plano. Cualquiera que estuviera en medio de la red —un compañero en la misma red local, un operador del proveedor, un atacante en un punto de acceso Wi-Fi— podía leerlo todo. SSH nació en 1995 para cerrar esa puerta sin renunciar a la comodidad de trabajar por terminal.

Técnicamente es un protocolo de red, no un programa. Eso significa que define mensajes, algoritmos y reglas de negociación, y que distintas implementaciones pueden hablar entre sí. La más extendida es OpenSSH, presente por defecto en prácticamente cualquier Linux, en macOS y en las versiones recientes de Windows. Existen otras (Bitvise en Windows, servidores SSH en equipos de red, bibliotecas para lenguajes de programación); en Windows, el cliente más conocido es PuTTY, pero el lenguaje común lo fija el estándar.

Sus rasgos esenciales:

• Es independiente del sistema operativo. Nació en el mundo Unix, pero hoy conecta Linux, macOS, Windows y dispositivos de red con la misma sintaxis.
• Usa el puerto TCP 22 por defecto. El número está documentado en el propio estándar y se puede cambiar, aunque hacerlo no es una medida de seguridad tan potente como a veces se cree —lo veremos en las buenas prácticas—.
• Autentica a los dos extremos. El servidor demuestra quién es al cliente, y el cliente demuestra quién es al servidor. Que el servidor también se identifique es lo que impide que alguien se ponga en medio haciéndose pasar por él.
• Cifra la sesión completa, ejecute comandos, transfiera archivos o abra un túnel entre puertos.

La arquitectura del protocolo está descrita en el RFC 4251 del IETF, que es la referencia primaria si quieres bajar al detalle. Es corto y sorprendentemente legible.

Cómo funciona SSH por dentro: tres capas

SSH se organiza en tres capas que se construyen una sobre otra. Saber distinguirlas explica por qué un error de autenticación no es lo mismo que un error de red, y por qué cambiar de algoritmo de cifrado no afecta a cómo se identifican los usuarios.

1. Capa de transporte

Es la base. Se encarga del intercambio inicial de claves, del cifrado de todo el tráfico, de comprobar la integridad de los mensajes y de la identificación del servidor. Está definida en el RFC 4253. Cuando abres una conexión, esta capa negocia qué algoritmos van a usar los dos extremos: el de intercambio de claves, el de cifrado simétrico, el de integridad (MAC) y el de compresión. Si no hay ningún conjunto de algoritmos en común, la conexión no llega a levantarse.

2. Capa de autenticación de usuario

Sobre el canal ya cifrado, el cliente demuestra quién es. Aquí entran la contraseña, las claves pública/privada, la autenticación por teclado interactivo y variantes como los certificados de confianza. Es el RFC 4252. Un punto importante: los datos de autenticación viajan dentro del túnel cifrado de la capa anterior, nunca antes de que exista cifrado.

3. Capa de conexión

Una vez autenticado, el cliente puede abrir varios «canales» lógicos sobre la misma sesión: una shell interactiva, una ejecución de comando suelta, un proceso de transferencia de archivos, un reenvío de puerto. Es lo que describe el RFC 4254. Que los canales sean independientes es la razón de que puedas tener una consola, un túnel a una base de datos y una transferencia por SFTP dentro de la misma conexión SSH.

Cifrado en SSH: claves, sesión y huellas

La palabra «cifrado» esconde aquí tres mecanismos distintos que trabajan juntos. Confundirlos es el origen de muchas dudas, así que vamos por partes.

La clave de sesión y el secreto hacia adelante

SSH no cifra toda la conversación con una sola clave eterna. Al principio, cliente y servidor hacen un intercambio de claves —habitualmente Diffie-Hellman, en su variante con curvas elípticas— del que ambos derivan una clave de sesión efímera. Esa clave se usa para el cifrado simétrico, que es rápido, y se descarta al cerrar la conexión.

La consecuencia práctica es el llamado forward secrecy o «secreto hacia adelante»: aunque alguien grabe hoy todo el tráfico y dentro de años consiga la clave privada del servidor, no podrá descifrar esta sesión concreta, porque la clave efímera ya desapareció. El algoritmo curve25519-sha256 es hoy la opción por defecto en las implementaciones modernas; su definición está en el RFC 8731.

Cifrado simétrico e integridad

Para cifrar los datos ya existe la clave de sesión. Los cifrados habituales hoy son [email protected] y las variantes de AES en modo GCM (cifrado autenticado, que también garantiza la integridad del mensaje). Además, cada paquete lleva un código de autenticación (MAC) que detecta cualquier manipulación: si alguien intenta alterar un byte por el camino, la conexión se corta. Nada de esto lo eliges a mano salvo que quieras afinar el endurecimiento; OpenSSH ofrece una lista de preferencias sensata de fábrica.

Claves de host, huellas y el fichero known_hosts

Antes de autenticarte, el cliente comprueba que el servidor es quien dice ser. Para eso el servidor tiene una clave de host (idealmente del tipo Ed25519), pública, que entrega al cliente. La primera vez que te conectas a una máquina, tu cliente guarda esa clave en known_hosts y te muestra su huella (fingerprint) para que la verifiques contra un canal de confianza. En las siguientes conexiones, si la clave no coincide, SSH te avisa con una alarma: o el servidor se ha reinstalado, o hay alguien en medio.

Ese aviso es exactamente la defensa contra el ataque man in the middle que mencionaba al principio. Ignorarlo a la ligera —pulsar «sí» sin mirar— es uno de los errores más caros y más fáciles de cometer.

Autenticación con claves: pública y privada

Aquí está la diferencia que más seguridad aporta en el día a día. En lugar de demostrar quién eres enviando una contraseña que el servidor conoce, SSH puede demostrarlo con un par de claves: una privada, que nunca sale de tu equipo, y una pública, que copias al servidor.

El funcionamiento es el de siempre en criptografía asimétrica. El servidor guarda tu clave pública. Cuando te conectas, te lanza un desafío; tú lo firmas con tu clave privada y él verifica la firma con la pública. La clave privada no viaja, y sin ella no hay firma posible. Por eso, si te roban el portátil y has protegido la clave con una passphrase, el atacante no puede usarla directamente.

El flujo típico, en la práctica:

# 1. Generar el par de claves (Ed25519, 100 rondas de derivación)
ssh-keygen -t ed25519 -a 100 -C "ana@portatil"

# 2. Copiar la clave PÚBLICA al servidor
ssh-copy-id -i ~/.ssh/id_ed25519.pub ana@servidor

# 3. Conectar (ya sin contraseña, pero con passphrase local)
ssh ana@servidor

Conviene fijar tres ideas:

• Lo que copias al servidor es la pública. La privada (~/.ssh/id_ed25519) no se mueve, no se comparte y se protege con permisos estrictos (chmod 600).
• La passphrase protege la clave en reposo, no la conexión. Se introduce una vez por sesión y luego la gestiona ssh-agent, que la mantiene en memoria para no repetirla.
• Ed25519 es la opción recomendada para claves nuevas: es compacta, rápida y su uso en SSH está estandarizado en el RFC 8709. RSA sigue siendo válido si necesitas compatibilidad con sistemas antiguos, pero con claves largas.

En entornos con muchas máquinas, gestionar centenares de claves autorizadas a mano se vuelve insostenible. Para eso existen los certificados SSH: una autoridad de confianza firma claves y el servidor acepta a cualquiera que presente un certificado válido, con caducidad y permisos. Es el mismo modelo que usan los certificados web, aplicado a las claves de acceso. Y no hay que olvidar que la autenticación va un paso por delante de la autorización: saber quién eres no decide qué puedes hacer. Esa segunda mitad se gestiona con permisos, sudo y modelos como el control de acceso basado en roles.

Túneles SSH y reenvío de puertos

Aquí es donde SSH deja de ser «un cliente de terminal» y se convierte en una navaja suiza. La capa de conexión puede transportar cualquier flujo TCP entre dos puntos, no solo comandos. A eso se le llama túnel SSH o port forwarding, y permite meter tráfico de otros protocolos dentro de una conexión cifrada y autenticada.

Hay tres modalidades que conviene distinguir porque se confunden todo el rato:

En la práctica se ven así:

# Reenvío local: el puerto 8080 de mi equipo apunta al 80 del servidor
ssh -L 8080:localhost:80 ana@servidor

# Reenvío remoto: el puerto 9000 del servidor apunta al 3000 de mi equipo
ssh -R 9000:localhost:3000 ana@servidor

# Proxy SOCKS5 local en el puerto 1080
ssh -D 1080 ana@servidor

Para administrar máquinas que no son accesibles directamente, la opción más limpia hoy es ProxyJump, que encadena la conexión a través de un equipo intermedio —el bastión o jump host— sin tener que abrir túneles a mano. Se escribe en el fichero ~/.ssh/config:

Host bastion
    HostName bastion.example.com
    User ana

Host interno
    HostName 10.0.0.20
    User ana
    ProxyJump bastion

Un túnel bien entendido es una herramienta de trabajo; mal usado, es un agujero de seguridad. Reenviar puertos abre caminos que el cortafuegos no ve, y el reenvío de agente (ForwardAgent) puede permitir que alguien en el servidor use tus claves para saltar a otros sistemas. Por eso los túneles se abren a propósito, se cierran al terminar y nunca se dejan configurados «por si acaso» en un equipo compartido.

Para qué se usa SSH en el mundo real

Más allá de la consola remota de manual, SSH sostiene buena parte de las operaciones de un sistema informático. Estos son los usos que de verdad te vas a encontrar:

• Administración remota de servidores. Es el caso clásico: entrar a una máquina Linux y trabajar como si estuvieras delante. También es la vía para lanzar comandos sueltos sin abrir sesión: ssh servidor "uptime".
• Transferencia de archivos con SFTP y SCP. Ambos protocolos viajan sobre SSH y cifran la transferencia. SFTP es interactivo y permite navegar; SCP es una copia directa y muy útil en scripts.
• Sincronización con rsync. rsync usa SSH como transporte por defecto y solo envía los cambios, lo que lo hace ideal para copias de seguridad entre máquinas.
• Git sobre SSH. Cuando haces git clone git@... estás autenticándote con tu clave SSH, no con usuario y contraseña. Es el método preferido por la mayoría de plataformas de código.
• Automatización y despliegue. Herramientas como Ansible, scripts de despliegue y pipelines de integración continua se conectan por SSH para instalar, actualizar y reiniciar servicios.
• Acceso a servicios internos mediante túneles. Bases de datos, paneles de administración o APIs que no están expuestas a Internet se alcanzan por un túnel a través de un bastión.
• Salto entre redes. Un equipo con acceso a varias redes puede actuar de puente, y SSH transporta la sesión por encima sin exponer cada salto.
• Contenedores y entornos de desarrollo. Conectar al shell de un contenedor, montar un servidor de desarrollo remoto o trabajar contra una máquina virtual suelen acabar siendo una sesión SSH.

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
X11Forwarding no
AllowUsers ana luis
LoginGraceTime 30
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2