¿Qué es SSH y cómo conectarte a un servidor?

Alquilas un pequeño servidor en la nube y el correo de bienvenida trae tres datos: una dirección IP, un nombre de usuario y la línea «Puerto SSH: 22». O el manual de un dispositivo de almacenamiento de tu red doméstica te pide abrir una terminal y escribir ssh admin@192.168.1.50. Los dos esperan lo mismo: que entres en esa máquina por SSH y trabajes en su línea de comandos como si estuvieras sentado delante.

Este artículo explica qué es SSH, qué ocurre al conectarte y cómo conectarte desde Windows, macOS y Linux. Después vienen la pregunta de la clave de host, las claves SSH frente a las contraseñas, los túneles, la diferencia entre SSH, TLS y una VPN, y cuándo SSH puede hacer de proxy.

¿Qué es SSH?#

SSH, siglas de Secure Shell, es un protocolo de red que te da una línea de comandos en un equipo remoto a través de una conexión cifrada. Un shell es el programa que lee los comandos que escribes y los ejecuta, como Bash en Linux o PowerShell en Windows; SSH lleva esa conversación por la red para que nadie en medio pueda leerla ni modificarla.

Intervienen dos programas. El cliente SSH se ejecuta en tu equipo e inicia la conexión; el servidor SSH, un programa en segundo plano que suele llamarse sshd, se ejecuta en la máquina remota y escucha por defecto en el puerto TCP 22. RFC 4251, el documento de arquitectura de la versión actual del protocolo, describe SSH como un protocolo para el inicio de sesión remoto seguro y otros servicios de red seguros sobre una red insegura.

La misma conexión cifrada también puede copiar archivos, ejecutar un solo comando o transportar otras conexiones de red, que es lo que hace un túnel SSH. Herramientas más antiguas como Telnet envían todo, contraseñas incluidas, como texto legible; SSH hace el mismo trabajo cifrado.

¿Cómo funciona una conexión SSH?#

Una conexión SSH se establece en un orden fijo: los dos lados acuerdan el cifrado, el servidor demuestra quién es y solo entonces inicias sesión. Esto es lo que ocurre después de ssh user@server.example:

1. Conexión TCP. Tu cliente se conecta al servidor, en el puerto 22 salvo que indiques otro.
2. Intercambio de versiones. Cada lado envía una línea que empieza por SSH-2.0- y nombra su software.
3. Intercambio de claves. Los dos lados enumeran los algoritmos que admiten, eligen unos comunes y calculan el mismo secreto sin enviarlo nunca. De ese secreto salen las claves de sesión que cifran todo a partir de aquí.
4. Autenticación del servidor. El servidor firma el resultado con su clave de host privada. Tu cliente comprueba la firma y compara la clave con la que guardó antes, o te pregunta si el servidor es nuevo.
5. Autenticación del usuario. Inicias sesión dentro de la conexión cifrada, con una contraseña o demostrando que tienes una clave SSH.
6. Canales. Tu shell, las transferencias de archivos y los puertos reenviados funcionan como canales separados dentro de esa única conexión.

RFC 4253, la especificación de la capa de transporte, define los pasos 1 a 4 y registra el puerto 22 como el asignado a SSH. Como cada conexión recibe claves de sesión nuevas, alguien que grabe tu tráfico hoy y robe más adelante la clave de host del servidor seguirá sin poder descifrar la grabación.

¿Cómo te conectas a un servidor con SSH?#

Escribes ssh, el nombre de usuario en el servidor, una @ y la dirección del servidor, y luego inicias sesión cuando te lo pida:

ssh user@server.example

user es la cuenta en el servidor, no en tu equipo, y server.example representa un nombre de host o una dirección IP como 203.0.113.10. Para un puerto distinto del 22, añade -p: ssh -p 2222 user@server.example. Tras la pregunta de la clave de host que se explica más abajo llega la contraseña; mientras la escribes, no aparece nada en pantalla. Cuando el indicador cambia a algo como user@server:~$, tus comandos se ejecutan en el servidor, y exit te devuelve a tu equipo.

En Windows#

Windows 10 (desde la compilación 1809) y Windows 11 incluyen un cliente OpenSSH, así que ssh funciona en PowerShell, en el Símbolo del sistema y en Windows Terminal. Para comprobarlo, ejecuta ssh -V. En nuestro equipo de pruebas con Windows 11 mostró:

OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2

Si Windows no reconoce ssh, abre Configuración > Sistema > Características opcionales, selecciona Ver características, busca OpenSSH Client y agrégalo; en algunas versiones de Windows 11, esa página está en Configuración > Aplicaciones. La guía de Microsoft sobre OpenSSH para Windows muestra estos pasos y una primera conexión.

En macOS y Linux#

Los dos traen un cliente SSH. En un Mac, abre Terminal desde Spotlight o desde la carpeta Aplicaciones > Utilidades y escribe el mismo comando. Si a un sistema Linux le falta ssh, instala su paquete de cliente OpenSSH, que suele llamarse openssh-client u openssh.

¿Por qué SSH pide confirmación en la primera conexión?#

SSH pregunta porque nunca ha visto la clave de host de este servidor y no puede saber por sí solo si la clave pertenece al servidor al que querías llegar. Una clave de host (host key) es un par de claves que el servidor crea cuando se configura SSH en él; su mitad pública identifica al servidor, igual que un certificado identifica a un sitio web.

OpenSSH muestra The authenticity of host … can't be established (no se puede comprobar la autenticidad del host) e indica el tipo de la clave y su huella digital (fingerprint), una suma de comprobación corta como SHA256: seguida de 43 caracteres. Luego pregunta Are you sure you want to continue connecting (yes/no/[fingerprint])?, es decir, si quieres seguir conectándote. Si respondes yes, el cliente guarda la clave en el archivo known_hosts de la carpeta .ssh de tu perfil de usuario y la comprueba en cada conexión posterior.

Antes de responder, compara la huella con una que hayas obtenido por otra vía: algunos proveedores de nube la muestran en la salida de la consola del servidor, y un administrador puede mostrarla en el servidor con ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. Aceptar una clave sin comprobarla te deja expuesto a un ataque de intermediario (man-in-the-middle), en el que alguien situado entre tú y el servidor se hace pasar por el servidor y lee tu contraseña.

Si un servidor conocido muestra de repente WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! (la identificación del host remoto ha cambiado), detente y pregunta a quien lo administra antes de borrar la entrada antigua; un servidor reinstalado es inofensivo, un impostor no. Nunca silencies la pregunta con StrictHostKeyChecking no: elimina la única comprobación que te dice quién está al otro lado.

¿Cómo se crea una clave SSH?#

Creas un par de claves SSH con ssh-keygen, que viene con el cliente SSH:

ssh-keygen -t ed25519 -C "you@laptop"

-t ed25519 elige el tipo Ed25519, que ya es el predeterminado en las versiones actuales de OpenSSH, y -C añade un comentario para reconocer la clave. El comando pregunta dónde guardar la clave (Intro acepta la carpeta .ssh de tu perfil de usuario) y pide una frase de contraseña (passphrase), una contraseña que cifra el archivo de la clave privada. Ponla: sin ella, cualquiera que copie el archivo puede iniciar sesión como tú.

En nuestro equipo de pruebas con Windows 11 guardamos una clave desechable en una carpeta de prueba con -f demo_ed25519 y la borramos después. Esta es la salida, sin la ruta de la carpeta:

Generating public/private ed25519 key pair.
Your identification has been saved in demo_ed25519
Your public key has been saved in demo_ed25519.pub
The key fingerprint is:
SHA256:lkosA9+FmCGq1dOjgIoIqQKwHR/jAMjzf+GsngbbGCc you@laptop

El archivo sin extensión es la clave privada: nunca sale de tu equipo. El archivo .pub es la clave pública, una sola línea que puedes compartir sin problema. El manual de ssh-keygen enumera todas las opciones, incluida la forma de cambiar la frase de contraseña.

Para iniciar sesión con clave, la línea de la clave pública va en ~/.ssh/authorized_keys de tu cuenta en el servidor. Muchos proveedores de nube te la piden al crear un servidor y la colocan ahí. En macOS y Linux, ssh-copy-id user@server.example la copia tras un inicio de sesión con contraseña; en Windows, abre el archivo .pub en el Bloc de notas, copia la línea, inicia sesión una vez con tu contraseña y pégala en ese archivo.

Contraseña o clave SSH: ¿qué inicio de sesión deberías usar?#

Usa una clave SSH siempre que puedas: una contraseña sirve para el primer inicio de sesión, pero una clave ya configurada es más segura y más cómoda.

El RFC que define los inicios de sesión SSH hace del inicio de sesión con clave el único método que todo servidor debe admitir; las contraseñas son opcionales.

¿Qué es un túnel SSH?#

Un túnel SSH lleva otra conexión de red dentro de tu sesión SSH cifrada, de modo que un programa de tu equipo puede llegar a un servicio del servidor, o cercano a él, como si fuera local. Esto se llama reenvío de puertos (port forwarding), y ssh ofrece tres tipos.

El reenvío local (-L) es el más común. Si tu servidor ejecuta una base de datos que solo escucha en su propia dirección 127.0.0.1, con ssh -L 5432:localhost:5432 user@server.example una herramienta de bases de datos de tu portátil se conecta a localhost:5432 y SSH entrega esa conexión a la base de datos del servidor. El reenvío remoto (-R) abre un puerto en el servidor que lleva de vuelta a tu equipo. El reenvío dinámico (-D) convierte el cliente en un pequeño proxy SOCKS, que es el tema de la siguiente sección.

El manual de OpenSSH para ssh describe cada opción. Usa los túneles solo en servidores que sean tuyos o que administres y en redes donde tengas permiso. Un túnel oculta su contenido a la red local, pero no lo vuelve permitido: si un centro educativo, una empresa o una autoridad bloquea un servicio, pasarlo por SSH sigue incumpliendo esas normas.

¿Puede SSH funcionar como proxy SOCKS5?#

Sí: ssh -D 1080 -N user@server.example inicia un proxy SOCKS5 en el puerto 1080 de tu propio equipo y envía lo que entra en él hacia fuera a través de tu servidor; -N no abre ningún shell, solo el túnel. Un proxy SOCKS5 retransmite las conexiones de un programa a cualquier dirección y puerto sin leerlas, como se explica en ¿Qué es un proxy SOCKS5?

Configura un navegador con el proxy SOCKS5 127.0.0.1 y el puerto 1080, y los sitios web verán la IP de tu servidor en lugar de la de tu conexión de casa. Las herramientas de línea de comandos suelen tomar su proxy de variables de entorno, que funcionan como se describe en configurar proxy en Linux.

Eso ayuda en tu propio trabajo, como comprobar tu sitio desde la ubicación del servidor. Los límites vienen incluidos: una sola IP de salida, una dirección de centro de datos en una sola ciudad, un servidor que mantienes tú y solo TCP, mientras que un proxy SOCKS5 también puede transportar UDP.

Cuando una tarea necesita más de una dirección, nuestros Proxies SOCKS5 funcionan con los mismos ajustes en los mismos programas y ofrecen IP residenciales y móviles en muchos países, con selección por país y ciudad.

Para una dirección fija, los Proxies de centro de datos te dan direcciones IPv4 dedicadas en más de 50 países sin que tengas que mantener un servidor.

SSH vs. SSL/TLS vs. VPN: ¿cuál es la diferencia?#

Los tres cifran el tráfico, pero protegen cosas distintas: SSH protege un inicio de sesión y las conexiones que se abren a través de él, TLS protege una conexión de una aplicación, como una página web, y una VPN protege todo lo que envía un dispositivo.

La diferencia práctica está en cómo empieza la confianza. Un navegador confía en un sitio web porque una autoridad de certificación respalda su certificado SSL, mientras que SSH confía en la clave que aceptaste en la primera conexión; por eso importa tanto comprobar esa huella.

¿Cómo mantienes seguro el acceso SSH a tu servidor?#

SSH es seguro si compruebas las claves de host, inicias sesión con claves y mantienes el servidor actualizado; las intrusiones vienen de contraseñas débiles y claves robadas, no del protocolo. Da por hecho que alguien intenta iniciar sesión todo el tiempo:

• Usa claves con frase de contraseña, una por persona, para poder quitar una sin tocar las demás.
• Desactiva el inicio de sesión con contraseña cuando tu clave funcione: PasswordAuthentication no en /etc/ssh/sshd_config de tu propio servidor Linux. Mantén una sesión abierta mientras pruebas, para que un error no te deje fuera.
• No inicies sesión como root con contraseña. La configuración predeterminada de OpenSSH ya solo permite root con claves; usa una cuenta normal y sudo.
• Instala las actualizaciones del sistema operativo y del servidor SSH.
• Protege la clave privada como una contraseña: nunca la pegues en un chat, un ticket o un repositorio.

Mover SSH a otro puerto solo reduce el ruido en los registros; la protección viene de las claves y las actualizaciones.

Dónde te encuentras con SSH#

• Servidores en la nube y planes VPS, que suelen administrarse por SSH desde el primer día.
• Hosting compartido, donde muchos planes ofrecen SSH junto al gestor de archivos.
• Git, donde direcciones como git@host:team/project.git suben y bajan código con tu clave.
• Transferencia de archivos con scp y sftp, que funcionan sobre SSH y también vienen con Windows.
• Dispositivos domésticos como almacenamiento en red y routers.
• Tu propio Mac, al que otros equipos pueden llegar por SSH cuando activas Sesión remota en Ajustes del Sistema > General > Compartir; Apple advierte que eso puede hacer que el Mac sea menos seguro.

Errores frecuentes#

• Escribir yes en la pregunta de la primera conexión sin comparar la huella.
• Silenciar los avisos de clave de host con StrictHostKeyChecking no en lugar de averiguar por qué cambió la clave.
• Enviar la clave privada en lugar del archivo .pub cuando alguien te pide «tu clave SSH».
• Desactivar el inicio de sesión con contraseña antes de que funcione el de clave, y perder el acceso al servidor.
• Usar el nombre de usuario equivocado. Muchas imágenes de nube usan una cuenta como ubuntu o admin en lugar de root, y un nombre equivocado termina en Permission denied.
• Esperar que las variables de entorno de proxy afecten a ssh. No lo hacen; SSH tiene su propia configuración en ~/.ssh/config.

Guía de decisión#

Preguntas frecuentes#

¿Es seguro SSH?#

Sí, si compruebas la clave de host en la primera conexión y proteges tu inicio de sesión. Los puntos débiles son las contraseñas fáciles de adivinar, las claves sin frase de contraseña y las huellas aceptadas sin comprobar, no el cifrado.

¿Qué es el puerto 22?#

El puerto 22 es el puerto TCP en el que escuchan por defecto los servidores SSH, asignado oficialmente a SSH. Un servidor puede usar otro puerto; entonces te conectas con ssh -p 2222 user@server.example o lo guardas en ~/.ssh/config con una línea Port.

¿Puedo usar SSH en el móvil?#

Sí. Las apps de cliente SSH para Android y iPhone se conectan con la misma dirección, el mismo usuario y el mismo puerto, y la mayoría pueden crear una clave en el teléfono cuya mitad pública añades al servidor. Compara también ahí la huella de la clave de host.

¿Qué significa Permission denied (publickey)?#

El servidor solo acepta inicios de sesión con clave, y ninguna de las claves que ofreció tu cliente figura para ese usuario. Revisa el nombre de usuario, si se usa la clave correcta (ssh -i elige una) y si su línea .pub está en ~/.ssh/authorized_keys de esa cuenta.

¿Qué diferencia hay entre SSH, SFTP y SCP?#

SSH es el protocolo y el inicio de sesión remoto; SFTP y SCP son herramientas de transferencia de archivos que funcionan dentro de una conexión SSH. sftp abre una sesión en la que recorres carpetas, scp copia archivos con un solo comando, y las dos usan el mismo inicio de sesión y las mismas claves que ssh.

¿Cómo cierro una sesión SSH?#

Escribe exit o pulsa Ctrl+D si el servidor ejecuta Linux o macOS. Si la sesión se cuelga, pulsa Intro y luego escribe ~. (virgulilla y punto): el cliente lo trata como una secuencia de escape y cierra la conexión desde tu lado.

En resumen#

SSH te da una línea de comandos cifrada en un equipo remoto: tu cliente se conecta al puerto 22, el servidor se identifica con una clave de host y tú inicias sesión con una contraseña o, mejor, con una clave creada con ssh-keygen. Comprueba la huella una vez, nunca desactives la comprobación de la clave de host y usa túneles solo donde tengas permiso. Cuando necesites más direcciones de salida de las que da un solo servidor, compara nuestros productos proxy.