--- title: "¿Qué es SSH y cómo conectarte a un servidor?" description: "SSH (Secure Shell) te da acceso cifrado a la línea de comandos de un servidor, por defecto en el puerto 22. Cómo funciona, cómo conectarte y las claves SSH." url: https://proxynet.io/es/blog/what-is-ssh date: 2026-11-15 author: "Acar Diveroli" category: "Tutoriales, Proxy 101" lang: es --- # ¿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. > **Nota: Respuesta breve** > > SSH (Secure Shell) es un protocolo para iniciar sesión en otro equipo y ejecutar comandos en él a través de una conexión cifrada. Usas un cliente SSH, como el comando `ssh`, que viene incluido en Windows 10 y 11, macOS y Linux, y te conectas a un servidor SSH, por defecto en el puerto TCP 22: `ssh user@server.example`. El servidor demuestra su identidad con una clave de host; tú demuestras la tuya con una contraseña o, mejor, con una clave SSH, y todo lo que sigue viaja cifrado. ## ¿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](https://www.rfc-editor.org/rfc/rfc4251), 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](https://www.rfc-editor.org/rfc/rfc4253), 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: ```bash 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ó: ```text 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](https://learn.microsoft.com/es-es/windows-server/administration/openssh/openssh_install_firstuse) 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: ```bash 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: ```text 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](https://man.openbsd.org/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. | | Inicio de sesión con contraseña | Inicio de sesión con clave SSH | |---|---|---| | Qué necesitas | La contraseña de la cuenta | El archivo de la clave privada y su frase de contraseña | | Qué llega al servidor | La contraseña, dentro del cifrado | Solo una firma; la clave se queda contigo | | Ataques por adivinación | Posibles contra contraseñas débiles | No son prácticos | | Contraseña reutilizada de un sitio filtrado | Abre el servidor | Sin efecto | | Scripts y copias de seguridad automáticas | Incómodo y arriesgado | Pensado para ello | | Si la pierdes | Un administrador la restablece | Añadir una clave pública nueva desde la consola | 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](https://man.openbsd.org/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?](/es/blog/socks5-proxy-101) 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](/es/blog/linux-proxy-settings). 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](https://proxynet.io/es/socks5-proxy) 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](https://proxynet.io/es/datacenter-proxy) 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. | | SSH | SSL/TLS | VPN | |---|---|---|---| | Qué protege | Tu sesión en un servidor | Una conexión, como HTTPS | Todo el tráfico del dispositivo | | Cómo se verifica el servidor | Clave de host, guardada en el primer uso | Certificado firmado por una autoridad | Depende del protocolo de la VPN | | Uso típico | Administración de servidores, transferencia de archivos | Sitios web, correo, API | Red de la oficina, wifi público | | Puerto predeterminado | 22 | 443 para HTTPS | Depende del protocolo | 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](/es/blog/what-is-an-ssl-certificate), 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 | Lo que necesitas | Qué hacer | |---|---| | Entrar en un servidor por primera vez | `ssh user@server.example`, compara la huella y después responde `yes` | | El servidor usa otro puerto | Añade `-p` y el número de puerto | | Dejar de escribir contraseñas | Crea una clave con `ssh-keygen` y añade la línea `.pub` a `authorized_keys` | | Llegar a una base de datos que solo escucha en el servidor | Reenvío local con `-L` | | Navegar con la IP de tu propio servidor | `ssh -D 1080 -N` y luego SOCKS5 `127.0.0.1:1080` | | Muchas ubicaciones o IP residenciales | Un servicio de proxy en lugar de un solo servidor | ## 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](/es/proxy).