SSH (Secure Shell): guía completa y práctica para usarlo bien

February 26, 2026 - By jaison-adm-wp

SSH (Secure Shell) es el estándar de facto para administrar sistemas remotamente de forma segura. Con SSH puedes abrir una shell en un servidor, ejecutar comandos, transferir archivos y crear túneles cifrados (port forwarding) para acceder a servicios internos como bases de datos, paneles privados o APIs internas.

1) ¿Qué es SSH y por qué reemplazó a Telnet?

SSH es un protocolo de acceso remoto cifrado, pensado para que todo lo que viaja entre tu máquina (cliente) y el servidor (daemon/servidor SSH) vaya protegido contra espionaje y manipulación.

Telnet, en cambio, transmite información en texto plano (incluyendo credenciales), por eso SSH lo reemplazó en la práctica.

2) Cómo funciona SSH por dentro (modelo mental)

SSH sigue un modelo cliente-servidor:

En el servidor corre un daemon SSH que escucha conexiones (normalmente en un puerto TCP) y autentica usuarios.
En tu máquina corre un cliente SSH (ssh) que negocia algoritmos, verifica identidad del servidor y autentica al usuario.

Durante la sesión:

Lo que escribes en tu terminal local viaja por un canal cifrado hacia el servidor, se ejecuta allí y el resultado vuelve por el mismo canal.

2.1 Cifrado y seguridad: simétrico, asimétrico e integridad (hash/MAC)

Una explicación útil (y muy didáctica) es pensar que SSH combina varias piezas:

Cifrado simétrico: se usa una clave de sesión para cifrar el tráfico de forma eficiente.
Integridad: además del cifrado, se usan hashes/MAC para detectar si alguien altera mensajes en tránsito (la idea del “hash cambia si cambias el contenido”).
Asimétrico (llaves): se usa para autenticación (y para establecer confianza/identidad), especialmente con llaves SSH.

Tip técnico: si quieres “ver” la negociación real (algoritmos, llaves, etc.), usa modo verbose:

ssh -vv usuario@servidor

(útil para depurar).

3) Autenticación: contraseña vs llaves SSH (lo profesional)

SSH normalmente permite autenticar por:

Contraseña (más fácil, menos segura).
Llaves SSH (recomendado).

3.1 Qué son las llaves SSH

Una “auth por llaves” es un par:

Llave privada (se queda en tu PC, no se comparte).
Llave pública (se copia al servidor).

En el servidor, la pública se guarda en:

~/.ssh/authorized_keys

En tu máquina (cliente), típicamente están en:

~/.ssh/ (por ejemplo id_rsa, id_ed25519, y sus .pub).

4) Generar llaves, usar passphrase y copiar la pública al servidor

4.1 Generar llaves

Ejemplo (ed25519 es una opción moderna y común hoy):

ssh-keygen -t ed25519 -C "tu-email-o-comentario"

Si usas passphrase, mejor: añade una capa de protección a tu llave privada.

4.2 Cambiar o remover passphrase

ssh-keygen -p

4.3 Copiar la llave pública con `ssh-copy-id`

Si ya puedes entrar por contraseña (al menos una vez), lo típico es:

ssh-copy-id usuario@servidor

4.4 Ver la huella (fingerprint) de una llave

ssh-keygen -l

5) Conexiones básicas: lo que usarás diario

Conectar:

ssh usuario@host

Ejecutar un comando remoto sin entrar a la shell interactiva:

ssh usuario@host "uname -a && uptime"

X11 forwarding (GUI remota, si aplica):

ssh -X usuario@host

6) Configuración del cliente: `~/.ssh/config` para trabajar más rápido

En vez de memorizar host/usuario/puerto/llave, define un alias:

Host mi-vps
  HostName 203.0.113.10
  User ubuntu
  Port 22
  IdentityFile ~/.ssh/id_ed25519

Luego:

ssh mi-vps

Esto también te ayuda a fijar un puerto no estándar sin escribir -p cada vez.

7) SSH Agent: evita escribir la passphrase cada conexión (sin perder seguridad)

Si tu llave tiene passphrase, ssh-agent te permite “cargarla” una vez por sesión:

eval "$(ssh-agent -s)"
ssh-add

Después podrás conectar sin reingresar la passphrase cada vez (hasta que reinicies sesión/terminal).

8) Túneles SSH (Port Forwarding): el superpoder para bases de datos y servicios internos

Un túnel es “encapsular” tráfico dentro de SSH. Lo normal es que no expongas tu BD al internet, sino que la accedes mediante túnel. SSH permite:

Local forward (-L)
Remote forward (-R)
Dynamic forward (-D, SOCKS)

8.1 Local forwarding (el más usado: traer una BD remota a tu PC)

Ejemplo típico MySQL/MariaDB:

ssh -N -L 3307:127.0.0.1:3306 usuario@servidor

Luego conectas tu cliente de BD a:

Host: 127.0.0.1
Puerto: 3307

8.2 Dejar el túnel en background

ssh -f -N -L 3307:127.0.0.1:3306 usuario@servidor

8.3 Cambiar/crear forwards sin cortar la sesión (`~C`)

Una joya poco usada de OpenSSH: dentro de una sesión abierta puedes abrir el prompt de control:

Enter
~C

Y ahí puedes agregar/eliminar forwards “en caliente”. La propia ayuda muestra comandos como -L, -R, -D y sus variantes de cancelación (-KL, -KR, -KD).

9) Endurecimiento (hardening) mínimo recomendado en servidores

Un baseline seguro suele incluir:

Preferir llaves sobre contraseñas.
Evitar accesos “peligrosos” de root (según tu política).
Restringir usuarios y métodos.

DigitalOcean también describe prácticas como forzar comandos específicos por llave en authorized_keys y opciones como PermitRootLogin forced-commands-only para escenarios controlados.

Importante: cualquier cambio en sshd_config requiere reiniciar el servicio (systemctl restart ssh/sshd) según distro.

10) Errores comunes que deberías reconocer

“Permission denied (publickey)”: la llave no coincide, no está en authorized_keys, estás usando otra identidad, o hay permisos mal puestos.
“Too many authentication failures”: pasa cuando tu agente ofrece demasiadas llaves y el servidor corta intentos; suele arreglarse especificando -i o ajustando ~/.ssh/config.
Advertencia de host key (cambio de fingerprint): revisa si cambió el servidor/reinstalación/IP o si hay riesgo de MITM.

11) Mini checklist para usar SSH “como pro”

Usa llaves (idealmente con passphrase).
Configura alias en ~/.ssh/config.
Usa ssh-agent para no tipear passphrase todo el día.
Para BD/servicios internos, usa -L (túnel) y evita exponer puertos públicos.
Depura con ssh -vv.