Si alguna vez has necesitado acceder a un servidor remoto, conectar a tu Raspberry Pi desde el sofá, o subir archivos a un hosting sin abrir el panel de control, seguramente has encontrado el término SSH. Probablemente también hayas leído que "es seguro" y que "deberías usar claves en lugar de contraseñas", pero quizá no sepas exactamente por qué, cómo funciona ni cómo dejar de escribir la contraseña cada dos por tres.

Este artículo es para ti. No necesitas ser administrador de sistemas ni tener un máster en ciberseguridad. Al final vas a poder generar tu propio par de claves SSH, conectar a un servidor sin escribir nunca más una contraseña, y configurar un alias para olvidarte incluso del nombre del host.

Qué es SSH y por qué no deberías usar telnet

SSH significa Secure Shell. Es un protocolo que te permite abrir una terminal en un ordenador remoto como si estuvieras sentado delante, pero con la diferencia de que toda la comunicación está cifrada. Si estás en tu portátil en casa y te conectas a un servidor en el otro lado del mundo, todo lo que haces —las órdenes que escribes, la salida que recibes, incluso la contraseña— viaja a través de un túnel cifrado que un observador en la red no puede leer.

Antes de SSH existía telnet, un protocolo anterior que hacía exactamente lo mismo… pero sin cifrar. Con telnet, cualquiera que estuviera espiando tu conexión podía leer tu nombre de usuario, tu contraseña y todo lo que hacías en el servidor, como si estuvieras hablando en voz alta. No hace falta decir que telnet cayó en desuso rápidamente. SSH, en cambio, se convirtió en el estándar porque combina la comodidad de la terminal remota con la seguridad del cifrado.

Lo que SSH ha reemplazado a telnet es solo el comienzo. Hoy en día, SSH es el mecanismo por el cual Git habla con GitHub, por el cual Docker Machine gestiona hosts remotos, por el cual herramientas como rsync o scp transfieren archivos de forma segura. Si usas la terminal con regular, ya estás usando SSH de alguna forma, aunque no lo sepas.

Claves SSH: el password que nunca escribirás

Cuando te conectas por SSH, el servidor necesita averiguar quién eres. La forma más obvia es pedirte un nombre de usuario y una contraseña. Pero esa es la peor opción. Las contraseñas se pueden olvidar, robar, adivinar o phfacear. Además, cada vez que te conectas, la estás escribiendo, y si usas la misma en varios servidores, un solo hueco es la puerta a todos ellos.

SSH resuelve esto con claves criptográficas. Un par de claves SSH consiste en dos archivos:

  • Una clave privada, que guardas en tu ordenador y nunca, jamás debes compartir. Es como tuDocumento de identidad: con ella pruebas quién eres.
  • Una clave pública, que puedes compartir libremente. La subes al servidor al que quieres acceder, y el servidor la usa para verificarte.

El proceso funciona así: el servidor cifra un mensaje con tu clave pública, y tú lo descifras con tu clave privada. Si logras descifrarlo, el servidor sabe que eres tú. Todo esto ocurre en milisegundos y, lo mejor, nunca la clave privada viaja por la red. Es imposible para un atacante interceptarla.

Las claves SSH son tan seguras y tan cómodas que, de hecho, es recomendable deshabilitar por completo el acceso con contraseña en un servidor y permitir solo conexiones con claves. Esa es la primera regla de oro de la administración remota.

Antes de generar: ¿ya tienes claves?

Es posible que ya hayas generado unas claves SSH en algún momento anterior y las hayas olvidado. Antes de crear nuevas, comprueba:

ice-tech
ls ~/.ssh/

Si ves archivos como id_ed25519 y id_ed25519.pub (o id_rsa y id_rsa.pub), ya tienes un par de claves. No necesitas crear otro. Si la carpeta no existe o está vacía, o si estás generando una clave nueva para un propósito concreto (como separar accesos de trabajo de accesos personales), entonces genera una nueva.

Puedes tener tantas claves como necesites y, de hecho, es buena práctica tener una clave por servicio o propósito. Por ejemplo, una para GitHub, otra para tu servidor de producción, y otra para tus experimentos con Raspberry Pi.

Generar tu par de claves SSH

El comando para generar claves es ssh-keygen. En los sistemas modernos, la recomendación es usar Ed25519, un algoritmo rápido, seguro y moderno que supera a RSA en prácticamente todo. Si tu servidor es antiguo y no soporta Ed25519, puedes usar RSA con -b 4096, pero la regla general es: Ed25519 por defecto, RSA solo si es estrictamente necesario.

Al ejecutar ssh-keygen, el programa te hará tres preguntas:

  1. ¿Dónde guardar la clave? Presiona Enter para aceptar la ubicación por defecto (~/.ssh/id_ed25519). Esa es la clave que SSH busca automáticamente.
  2. ¿Qué frase de paso (passphrase) usar? Aquí sí conviene añadir una capa extra: una frase de paso breve pero memorable. No es obligatoria, pero protege tu clave privada en caso de que algún día alguien acceda físicamente a tu disco. La passphrase es como el PIN de una tarjeta bancaria: una capa adicional que no deberías saltarte si puedes evitarlo.
  3. ¿Confirmar la frase de paso? Repite la misma frase.
ice-tech
$ ssh-keygen -t ed25519 -C "[email protected]"

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/usuario/.ssh/id_ed25519
Your public key has been saved in /home/usuario/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:x8uS0q4f...F3a9 usuario@ordenador
The key's randomart image is:
+---[ED25519 256]---+
|      .o.  +.      |
|     o +o o.+      |
|   .+ o .= o .     |
...
+----[SHA256]-------+

El flag -C añade un comentario (normalmente tu email) a la clave pública, lo que te ayuda a identificarla más tarde. No cambia la seguridad de la clave, pero es una etiqueta útil cuando gestionas varias.

Cuando termina, en ~/.ssh/ tendrás dos archivos:

  • id_ed25519 — tu clave privada. Permisos 600 (solo tú puedes leerla).
  • id_ed25519.pub — tu clave pública. Puedes compartirla libremente.

Nunca compartas el archivo .pub sin antes entender qué contiene, y nunca subas la clave privada a un servidor, a un repositorio de Git, ni a ningún lado. Si sospechas que se ha comprometido, revoca la clave inmediatamente y genera una nueva.

Subir la clave pública al servidor

Tener una clave no basta: el servidor necesita saber quién eres. Para eso, copias tu clave pública al archivo ~/.ssh/authorized_keys dentro del servidor. El comando ssh-copy-id hace exactamente eso de forma automática:

ice-tech
ssh-copy-id usuario@host-o-ip

Te pedirá la contraseña del servidor (sí, la primera y última vez que la escribes). Si todo va bien, verás algo como:

ice-tech
Number of key(s) added: 1
Try your SSH connection now.

Eso significa que tu clave pública se instaló correctamente. A partir de ahora, cada vez que te conectes, el servidor usará la clave para verificarte sin pedirte la contraseña.

Si por alguna razón ssh-copy-id no está disponible en tu sistema, puedes hacerlo manualmente: conecta al servidor con contraseña, crea la carpeta .ssh si no existe, pega tu clave pública en authorized_keys y ajusta los permisos. Pero ssh-copy-id es la forma limpia, rápida y sin errores.

En sistemas donde el servidor usa un puerto distinto al 22 (algo muy común por seguridad), añade el flag -p:

ice-tech
ssh-copy-id -p 2222 usuario@host-o-ip

Conectarte sin contraseña

Una vez que la clave está en el servidor, la magia sucede: simplemente escribes ssh con tu usuario y el host, y ya estás dentro. Sin contraseñas interminables, sin cuadros de diálogo.

ice-tech
$ ssh [email protected]
Welcome to Ubuntu 22.04 LTS ...
usuario@servidor:~$

El prompt te cambia de tu máquina local a la del servidor. Cualquier comando que ejecutes ahora corre en ese otro ordenador. Cuando quieras volver, escribe exit o pulsa Ctrl + D.

Hay un detalle práctico: la primera vez que te conectas a un servidor, SSH te mostrará el hash de huella digital del servidor y te preguntará si confías en él. Escribe yes y se guardará en ~/.ssh/known_hosts. Es un mecanismo de protección contra man-in-the-middle: si un día el servidor cambia su identidad (por una reinstalación o, peor, por un ataque), SSH te lo avisará con un error de clave huerfana.

El archivo de configuración: ~/.ssh/config

A medida que trabajas con más servidores, escribir ssh [email protected] -p 2222 se vuelve tedioso. La solución es el archivo de configuración de SSH: ~/.ssh/config. Allí puedes definir alias para cada servidor con todos sus datos:

ice-tech
Host raspberry
    HostName 192.168.1.50
    User pi
    Port 22

Host produccion
    HostName 203.0.113.45
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519-prod

Con eso, en lugar de recordar la IP, el usuario y el puerto, solo escribes:

ice-tech
ssh raspberry
ssh produccion

Y para subir archivos con scp, también funciona:

ice-tech
scp archivo.txt produccion:~/backups/

El archivo config también soporta comodines. Un Host *.ejemplo.com aplica a todos los subdominios, y puedes anidar reglas. Es especialmente útil cuando administas varios servidores con la misma configuración base.

⚠️ Permisos correctos: el archivo ~/.ssh/config debe tener permisos 600 (solo lectura/escritura para el propietario). Si los permisos son más abiertos, SSH rechazará el archivo con un error de "bad permissions". Lo mismo aplica al directorio ~/.ssh/ (debe ser 700) y a las claves privadas (600).

Otras operaciones útiles con SSH

SSH no sirve solo para abrir terminales. También puedes:

  • Reenviar puertos (-L y -R): acceder a un servicio que corre en el servidor localmente, o exponer un servicio local al servidor. Muy útil para probar APIs en desarrollo.
  • Reenviar agentes (-A): usar tu clave SSH local dentro del servidor remoto, para, por ejemplo, clonar un repositorio de GitHub desde dentro del servidor sin configurar claves allí.
  • Ejecutar un comando único: ssh usuario@host "uptime" ejecuta el comando y vuelve. Ideal para checks rápidos o scripts de monitorización.
  • Copiar directorios completos: scp -r carpeta/ usuario@host:/destino/ transfiere toda una carpeta a la vez.

Problemas comunes y cómo resolverlos

  • Permission denied (publickey): ocurre cuando el servidor no reconoce tu clave. Comprueba que has subido la clave pública correcta a authorized_keys, que los permisos del directorio .ssh y el archivo authorized_keys son correctos (700 y 600, respectivamente), y que estás usando la clave privada adecuada si tienes varias.
  • Host key verification failed: el servidor cambió su huella o estás intentando conectarte a un host falso. Edital ~/.ssh/known_hosts, busca la línea del host y bórrala, luego vuelve a conectar para aceptar la nueva huella.
  • ssh: connect to host … port 22: Connection refused: el servidor no tiene SSH activo, está en un puerto distinto (usa -p) o el firewall lo bloquea. Verifica con ssh -p 2222 o contacta al administrador.
  • Permission denied, please try again: si ya usabas contraseña, puede que el servidor tenga deshabilitadas las contraseñas (solo claves). Configura tu clave pública con ssh-copy-id.
  • Bad owner or permissions: el problema está en los permisos de algún archivo en ~/.ssh/. Ejecuta chmod 700 ~/.ssh/ && chmod 600 ~/.ssh/config ~/.ssh/id_ed25519 && chmod 644 ~/.ssh/id_ed25519.pub.

Un truco de diagnóstico profesional: usa ssh -v usuario@host (la vocal v se puede repetir hasta -vvv para más detalle). SSH mostrará, paso a paso, qué está haciendo: qué clave está probando, qué respuesta da el servidor, por dónde falla. La salida es verborreica, pero suele señalar el problema exacto.

Seguridad: más allá de la clave

Usar claves SSH es un gran paso, pero no es el único aspecto de la seguridad:

  • Deshabilita el acceso root por SSH: en el servidor, edita /etc/ssh/sshd_config y pon PermitRootLogin prohibit-password. Obliga a conectar con un usuario sin privilegios y elevar con sudo.
  • Cambia el puerto: si el servidor es público, mover SSH del puerto 22 al 2222 o 11022 reduce el ruido de escáneres automáticos.
  • Usa fail2ban: bloquea IPs que intentan forzar el acceso repetidamente.
  • Frase de paso: no dejes tu clave privada sin passphrase. Si alguien roba tu portátil, la clave privada es inútil sin la passphrase.

Conclusión

SSH con claves no es un "trucos de expertos": es la base mínima sobre la que descansan casi todas las operaciones remotas en servidores, desde desplegar una aplicación hasta hacer copias de seguridad. Dedicar media hora a configurarlo bien te ahorrará contraseñas interminables, accesos fallidos y, sobre todo, te da una base segura para trabajar remoto.

La receta es corta: genera una clave con ssh-keygen -t ed25519, súbela con ssh-copy-id, conéctate con ssh y, de paso, crea un alias en ~/.ssh/config para no escribir direcciones largas. La terminal te ha dejado de dar miedo: es ahora tu atajo directo a cualquier servidor del mundo.

Mi consejo final: abre la terminal y prueba el flujo completo. Conéctate a tu propio ordenador (si tienes SSH activado) o a una máquina virtual gratuita. Verás que, una vez que funciona el primer login sin contraseña, todo cuadra. No hay magia, solo una herramienta bien diseñada que, como Git o rsync, se vuelve invisible precisamente por estar bien hecha.