Como funciona SSH y para que sirve

¿Qué es SSH?

SSH (secure shell) es un protocolo para iniciar sesión en un equipo remoto y ejecutar comandos en él a través de una conexión cifrada. Lo que usted escribe se envía a la máquina remota, su salida regresa y nadie que supervise la red intermedia puede leer ninguno de los dos. Un servidor Linux alquilado no tiene pantalla ni teclado conectados, por lo que SSH es el medio para utilizar la máquina.

El nombre abarca dos conceptos. SSH es el protocolo, descrito en los RFC 4251 a RFC 4254. OpenSSH es el programa que lo implementa, y es el que ejecutan casi todos los servidores Linux y casi todos los portátiles. Cuando alguien dice "hacer SSH al servidor", se refiere al programa cliente ssh en su máquina comunicándose con el programa servidor sshd en el otro extremo.

El problema que SSH se creó para reemplazar

El inicio de sesión remoto es mucho más antiguo que SSH. Telnet abría una conexión TCP sin cifrar al puerto 23 y enviaba cada byte exactamente como se escribía. Nada estaba cifrado, lo cual incluía su contraseña. Cualquiera que pudiera ver el tráfico podía leerlo: una persona en la misma red de oficina o el operador de cualquier router a lo largo de la ruta. La familia rlogin tenía la misma debilidad y confiaba en la máquina cliente por su nombre, lo que significa confiar en lo que la red afirmara que era ese nombre.

Tatu Ylönen escribió el primer SSH en 1995 en la Universidad Tecnológica de Helsinki, después de un ataque de captura de contraseñas en la red universitaria. El diseño conserva la parte útil de telnet, un flujo de bytes entre su terminal y una shell remota, y añade las dos cosas para las que telnet no tiene respuesta: el cifrado del flujo y la prueba de que el servidor en el otro extremo es al que usted pretendía llegar.

Esa segunda parte es fácil de pasar por alto y es la mitad de lo que es SSH. El cifrado por sí solo no le salvaría. Una máquina en el medio podría aceptar su conexión, cifrarla perfectamente, leer todo lo que usted envía y pasarlo al servidor real. SSH bloquea esto otorgando a cada servidor una identidad permanente, llamada host key, y verificándola en cada conexión.

Cómo funciona el modelo cliente-servidor

Existen dos programas. En el servidor, sshd se ejecuta permanentemente y espera conexiones. En su máquina, ssh las establece. Son programas independientes con archivos de configuración separados, y confundirlos es la causa más común de que una edición no surta efecto.

• El servidor lee /etc/ssh/sshd_config. Aquí es donde se deshabilita el inicio de sesión con contraseña y se configura el puerto de escucha.
• El cliente lee /etc/ssh/ssh_config para los valores predeterminados del sistema y, posteriormente, ~/.ssh/config para sus ajustes específicos por host.

En Debian y Ubuntu, la unidad de servicio se llama ssh. En RHEL, Rocky y Fedora se llama sshd. Las versiones recientes de Ubuntu lo instalan con activación por socket, por lo que systemctl status ssh puede informar inactive (dead) mientras la máquina es perfectamente accesible, ya que ssh.socket es la unidad que realiza la escucha e inicia el servicio bajo demanda.

El cliente no tiene por qué ser OpenSSH. PuTTY en Windows, Termius en un teléfono y el soporte remoto integrado en editores utilizan el mismo protocolo para comunicarse con el mismo sshd. Windows 10 y 11 también incluyen el cliente OpenSSH, por lo que ssh you@server funciona en PowerShell sin necesidad de instalar nada.

¿Por qué SSH utiliza el puerto 22?

Un puerto es un número que indica al kernel a qué programa en escucha pertenece una conexión entrante, y los puertos en Linux funcionan de la misma manera para cada servicio. SSH utiliza el 22 porque la IANA lo asignó en 1995. Ylönen solicitó un número libre situado junto a los protocolos que SSH fue diseñado para reemplazar: el 21 era FTP, el 23 era telnet y el 22 estaba sin usar.

Debido a que el 22 es el predeterminado, todo el software lo asume. Su remoto de Git, su script de respaldo y el panel de control de su proveedor intentan conectar primero al 22. Lo mismo hace cada escáner automatizado en Internet. Un servidor nuevo con el inicio de sesión por contraseña habilitado comienza a acumular líneas como esta en /var/log/auth.log a los pocos minutos de arrancar:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Ese tráfico es constante y no está dirigido a usted personalmente. Mover sshd al puerto 2222 elimina la mayoría de esas líneas, porque los escáneres están rastreando todo Internet en el puerto 22 en lugar de analizar su servidor específicamente. Esto no hace que la máquina sea más difícil de vulnerar para alguien que realmente la examine. Considere el cambio de puerto únicamente como una medida de reducción de ruido.

Puede observar cómo el servidor responde antes incluso de iniciar sesión:

nc 203.0.113.10 22

En Ubuntu 24.04, esto imprime algo similar a SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. El banner se envía en texto plano, antes de que exista cualquier cifrado, porque ambos extremos lo necesitan para acordar la versión del protocolo. Presione Ctrl+C para cerrar la conexión.

Qué ocurre en la red al conectar

La siguiente secuencia es lo que hace un ssh you@server antes de que usted vea un prompt.

1. El cliente resuelve el nombre de host a una dirección IP y abre una conexión TCP al puerto 22.
2. Ambos extremos envían su banner de versión en texto plano.
3. Ambos extremos envían las listas de algoritmos que soportan: intercambio de claves, cifrado, autenticación de mensajes y compresión. Sigue siendo texto plano. Se elige la opción más robusta que ambos conocen.
4. Se ejecuta el intercambio de claves. El OpenSSH actual prefiere curve25519-sha256. Ambos extremos terminan con el mismo secreto compartido sin que este cruce la red, por lo que alguien que haya grabado toda la conversación no puede deducirlo después.
5. El servidor firma el resultado de ese intercambio con su clave privada de host. Su cliente verifica la firma contra la clave pública del host que tiene registrada. Este es el paso que impide que una máquina intermedia suplante a su servidor.
6. Comienza el cifrado. chacha20-poly1305@openssh.com es el cifrado predeterminado en el OpenSSH actual.
7. Solo ahora el cliente le autentica, mediante contraseña o clave. Su nombre de usuario y contraseña viajan dentro del canal cifrado.
8. El cliente abre un canal y solicita una shell.

El orden en esa lista es la diferencia total respecto a telnet. La autenticación ocurre después de que el canal esté cifrado y después de que el servidor haya probado su identidad, por lo que no hay momento en que su contraseña viaje por la red al descubierto.

Alguien que observe la red aún puede obtener información. Verá su dirección IP, la dirección IP del servidor, el puerto 22, ambos banners de versión en texto plano, y la temporización y tamaño aproximado de cada paquete. No verá su nombre de usuario, su contraseña, sus comandos ni su salida. La resolución del nombre de host en el paso 1 no es parte de SSH y generalmente no es privada, por lo que la consulta DNS que resuelve el nombre de su servidor puede revelar a qué máquina está a punto de acceder, aunque la sesión en sí permanezca sellada.

La clave de host y el aviso de huella digital en la primera conexión

Cuando se instala openssh-server, este genera pares de claves de host para la máquina y los escribe en /etc/ssh/, por ejemplo en ssh_host_ed25519_key y ssh_host_ed25519_key.pub. La parte privada nunca abandona el servidor. La parte pública es la identidad del servidor y es contra la que se verifica la firma en el paso 5.

La primera vez que se conecta a un servidor nuevo, su cliente no tiene nada con qué comparar, por lo que le pregunta:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

La huella digital es un hash SHA256 de la clave pública del host, impreso en base64, por lo que es lo suficientemente corto como para compararlo a simple vista. Escribir yes guarda esa clave en ~/.ssh/known_hosts en su propia máquina. Cada conexión posterior a la misma dirección compara la clave que ofrece el servidor con la almacenada. Cuando coinciden, no se imprime nada y usted accede directamente a su prompt.

Este modelo se denomina confianza en el primer uso (trust on first use) y es necesario ser honesto sobre lo que implica. La primera conexión es el único momento en el que usted no está protegido, porque está aceptando una clave que nunca antes había visto. Para cerrar esa brecha, obtenga la huella digital por otra vía y compárela. La mayoría de los proveedores la imprimen en la salida de arranque que se muestra en su consola web, y usted también puede imprimirla en el propio servidor:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Esto imprime la misma cadena SHA256: que le mostró el aviso. La opción [fingerprint] en el aviso existe exactamente para esto: pegue la huella digital que espera y el cliente continuará solo si coincide con lo que presentó el servidor.

En Debian y Ubuntu, known_hosts se aplica hash de forma predeterminada, por lo que el archivo contiene líneas que comienzan con |1| en lugar de nombres de host legibles. Ejecute ssh-keygen -F 203.0.113.10 para encontrar la entrada de un host específico.

¿Por qué SSH indica que la clave del host ha cambiado?

Tarde o temprano se encontrará con este bloque de texto:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Termina con Host key verification failed. y el cliente rechaza la conexión. También muestra Password authentication is disabled to avoid man-in-the-middle attacks., ya que introducir su contraseña en una máquina desconocida es precisamente el daño que esta comprobación evita.

El mensaje parece una emergencia, pero la mayoría de las veces no lo es. Las causas habituales son:

• Reinstaló o reconstruyó el servidor, por lo que sshd generó nuevas claves de host en el primer arranque. Esta es, con diferencia, la razón más común.
• Destruyó un VPS y creó otro, y el proveedor asignó la dirección IP antigua a la nueva máquina.
• Se está conectando a través de un reenvío o un balanceador de carga que ahora alcanza una máquina backend distinta.
• Algo está interceptando realmente la conexión.

Determine cuál es el caso antes de borrar nada. Si reinstaló la máquina hace diez minutos, la causa es evidente. Si no ha cambiado nada por su parte, deténgase e investigue, ya que esta advertencia es el mecanismo de seguridad cumpliendo su función. Una vez que esté seguro, elimine la entrada obsoleta y vuelva a conectarse:

ssh-keygen -R 203.0.113.10

La siguiente conexión mostrará de nuevo el aviso de huella digital, lo que le brinda una nueva oportunidad para compararla con la consola del proveedor.

Inicio de sesión con contraseña frente a inicio de sesión con clave

La autenticación por contraseña envía su contraseña dentro del canal ya cifrado, y sshd la verifica contra la base de datos de cuentas, normalmente a través de PAM (módulos de autenticación conectables). No requiere preparación, razón por la cual un proveedor puede entregarle un servidor nuevo solo con una contraseña de root.

La debilidad no es el cifrado. Es que una contraseña es un secreto corto, usted la envía al servidor en cada inicio de sesión y el puerto 22 es objeto de intentos de adivinación constantes por parte de máquinas que nunca se cansan.

La autenticación por clave pública funciona de forma diferente. Usted crea un par de claves en su propia máquina. La mitad pública va a ~/.ssh/authorized_keys dentro de su cuenta en el servidor. La mitad privada permanece en su equipo y nunca se transmite. Para iniciar sesión, el cliente firma un fragmento de datos que incluye el identificador de sesión del intercambio de claves, y el servidor verifica esa firma utilizando la clave pública que ya posee. Debido a que los datos firmados están vinculados a esta única sesión, una firma capturada no sirve para nada en otros contextos.

Preste atención a la dirección, ya que invertirla es común y perjudicial: la clave pública va al servidor, la clave privada se queda con usted. Una clave privada copiada en un servidor es una clave privada en la que ya no puede confiar.

El inicio de sesión con clave tiene sus propios modos de fallo. sshd ignora las claves cuando los permisos de archivo son demasiado permisivos, y lo indica en el registro del servidor:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

El cliente solo le dirá Permission denied (publickey), que es el mismo mensaje para una docena de causas diferentes, por lo que vale la pena aprender a interpretar correctamente el error de publickey antes de quedar bloqueado. El trabajo práctico de crear claves, protegerlas con una frase de contraseña y cargarlas en un agente se detalla en gestión de claves SSH, y desactivar el inicio de sesión con contraseña sin quedarse fuera se explica en endurecimiento de SSH en un VPS.

SFTP, scp y el reenvío de puertos utilizan la misma conexión

Esta es la idea que permite comprender el resto del ecosistema SSH. La autenticación abre una conexión cifrada, y dicha conexión puede transportar varios canales independientes de forma simultánea. Una shell es solo un tipo de canal entre varios.

• Una shell remota. ssh you@server abre un canal de sesión y solicita una shell interactiva.
• Un comando único. ssh you@server uptime abre un canal, ejecuta un comando, imprime la salida y termina.
• SFTP. El cliente solicita a sshd que inicie su subsistema sftp, y la transferencia de archivos se ejecuta dentro de la misma conexión. SFTP es un protocolo de transferencia de archivos que utiliza SSH y no comparte diseño alguno con FTP. El protocolo que consiste en FTP con cifrado añadido se denomina FTPS y no tiene relación.
• scp. Copia archivos utilizando el mismo inicio de sesión. Desde OpenSSH 9.0, publicado en 2022, scp utiliza el protocolo SFTP de forma predeterminada.
• Reenvío de puertos. ssh -L 8080:localhost:80 you@server convierte el puerto 8080 de su equipo local en una puerta de acceso al puerto 80 del servidor, transportada dentro de la conexión cifrada. -R realiza el reenvío en la dirección opuesta, y -D 1080 convierte la sesión en un proxy SOCKS.
• Git. Un remoto como git@github.com:user/repo.git es un inicio de sesión SSH cuyo extremo remoto ejecuta un gestor de comandos en lugar de una shell.
• rsync y Ansible también son clientes SSH. Abren un canal, ejecutan una tarea y leen la salida resultante.

Cada elemento de esta lista utiliza el mismo puerto, la misma comprobación de clave de host y las mismas credenciales. Por eso, configurar la autenticación por clave una vez compensa el esfuerzo de inmediato: cada una de estas herramientas la hereda. Es también la razón por la que el mismo archivo ~/.ssh/config que simplifica sus inicios de sesión es el archivo que permite escalar cuando está administrando varios servidores Linux desde un solo equipo.

Lo que SSH no hace

• No hace que su servidor sea seguro. SSH protege el camino hacia la puerta. La puerta sigue ahí y los usuarios seguirán intentando abrirla. Bloquear intentos de inicio de sesión repetidos con fail2ban gestiona el volumen de intentos, y la autenticación basada únicamente en claves elimina el elemento que intentan adivinar.
• No le protege de su propia máquina. Cualquier persona con acceso a su portátil tiene su clave privada y su agente cargado.
• No oculta que está utilizando SSH. El número de puerto y el banner de versión en texto plano lo anuncian.
• No cubre lo que sucede antes de que exista la conexión. La resolución de nombres y su decisión sobre qué dirección confiar ocurren primero.

Pasos a seguir

Si tiene un servidor nuevo abierto en la consola de un proveedor, el orden de actuación es fijo. Acceda, cree un usuario normal, instale su clave y cierre las rutas de acceso fáciles tras usted. Los primeros diez minutos en un VPS nuevo detalla ese proceso de principio a fin, y qué es realmente un VPS explica la máquina subyacente si los términos aún le resultan nuevos. Después, las claves y el endurecimiento (hardening) son las dos publicaciones que debe leer, en ese orden.

FAQ

¿Qué significa SSH?

SSH significa secure shell. Es un protocolo para iniciar sesión en un equipo remoto y ejecutar comandos sobre una conexión cifrada, definido en los RFC 4251 a RFC 4254. OpenSSH es la implementación que utiliza casi todo el mundo: el cliente ssh en su máquina y el servidor sshd en la máquina remota. Reemplazó a telnet, que enviaba todo, incluidas las contraseñas, a través de la red en texto plano.

¿Por qué SSH utiliza el puerto 22?

IANA asignó el puerto 22 a SSH en 1995, junto a FTP en el 21 y telnet en el 23, los protocolos a los que estaba destinado a reemplazar. Nada obliga a usar ese número: Port en /etc/ssh/sshd_config lo cambia en el servidor, y ssh -p selecciona uno diferente en el cliente. Como 22 es el valor predeterminado, los escáneres automatizados llaman a esa puerta constantemente, razón por la cual el /var/log/auth.log de un servidor recién instalado se llena de líneas Failed password for invalid user. Cambiar el puerto reduce ese ruido, pero no añade una protección real.

¿Qué debo hacer cuando SSH advierte que la clave de host ha cambiado?

Encuentre la causa antes de borrar nada. La razón habitual es inofensiva: el servidor se reconstruyó, por lo que sshd generó nuevas claves de host, o se asignó una máquina nueva a la dirección IP antigua. Si sabe que la máquina fue reconstruida, ejecute ssh-keygen -R <host> para eliminar la clave almacenada, vuelva a conectarse y compare la huella digital que se le muestra con la que informa la consola de su proveedor. Si no ha cambiado nada por su parte, no se conecte y no introduzca su contraseña. OpenSSH ya rechaza la autenticación por contraseña en este estado precisamente por esa razón.

¿Son SFTP y scp diferentes de SSH?

Se ejecutan sobre él. Una vez autenticado, la conexión SSH puede transportar varios canales, y una shell es solo uno de ellos. SFTP es un protocolo de transferencia de archivos que utiliza el subsistema sftp de sshd sobre esa misma conexión, y scp ha utilizado el protocolo SFTP internamente desde OpenSSH 9.0. El reenvío de puertos y Git sobre SSH también son canales en la misma conexión. Todos utilizan el mismo puerto, la misma comprobación de clave de host y el mismo inicio de sesión. Tenga en cuenta que SFTP no es FTP con cifrado añadido; ese se llama FTPS y es un protocolo independiente.

¿Es la autenticación por clave realmente mejor que una contraseña?

Sí, para cualquier servidor accesible desde Internet. Una contraseña es un secreto corto que usted entrega al servidor en cada inicio de sesión, y el puerto 22 es objeto de intentos de adivinación continuos por parte de clientes automatizados. Con un par de claves, la mitad privada nunca abandona su máquina: el cliente firma los datos vinculados a la sesión actual y el servidor comprueba esa firma contra la clave pública en ~/.ssh/authorized_keys. Una firma registrada no puede ser reutilizada contra otro servidor. Proteja la clave privada con una frase de contraseña, ya que un archivo de clave sin ella es un acceso funcional para cualquiera que lo copie.