Configurar SSH con claves públicas: guía paso a paso

📅 Publicado el 28 de octubre, 2026 · Por Equipo RedServicio

Proteger un servidor o un plan de hosting pasa casi siempre por lo mismo: dejar atrás el acceso por contraseña y cambiarlo a claves SSH. No es complicado, pero conviene hacerlo bien. Aquí tienes el proceso completo: generar el par de claves, copiarlas al servidor y comprobar que todo entra. Si administras una web en un VPS o en un hosting con acceso SSH, el rato que le dediques te evitará más de un susto de seguridad.

¿Por qué usar claves SSH en lugar de contraseñas?

Una contraseña, por buena que sea, se puede adivinar. Los ataques de fuerza bruta existen precisamente porque herramientas automatizadas prueban miles de combinaciones por minuto sin cansarse. Las claves SSH funcionan de otra manera, mediante criptografía asimétrica con un par de claves:

• Clave privada: se guarda en tu equipo y nunca debe salir de él.
• Clave pública: se instala en el servidor; puede compartirse sin riesgo.

¿Cómo decide el servidor quién entra? Solo permite el acceso a quien demuestre poseer la clave privada correspondiente, un reto matemático que hoy por hoy resulta imposible de resolver por fuerza bruta. Y hay algo más: puedes desactivar del todo el acceso por contraseña, con lo cual los ataques automatizados se quedan literalmente sin puerta.

Ventajas principales

• Autenticación sin escribir contraseñas en cada conexión.
• Posibilidad de añadir una passphrase a la clave privada para una capa extra de seguridad.
• Automatización de tareas: deploys, copias de seguridad con rsync o scripts cron.
• Registro claro de qué clave accedió y cuándo, útil para auditar el servidor.

Cómo generar tu par de claves SSH con ssh-keygen

La herramienta ssh-keygen viene incluida por defecto en Linux, macOS y en Windows 10/11 (desde PowerShell o CMD). Abre una terminal y ejecuta:

ssh-keygen -t ed25519 -C «[email protected]»

El algoritmo ed25519 es el recomendado hoy por su seguridad y rapidez. Si tu servidor es antiguo y no lo soporta, usa RSA con al menos 4096 bits: ssh-keygen -t rsa -b 4096.

A continuación, el sistema te pedirá dos cosas:

1. Ruta del archivo: pulsa Enter para aceptar la ubicación por defecto (~/.ssh/id_ed25519).
2. Passphrase: escribe una frase de seguridad (muy recomendable). Si dejas el campo vacío, cualquiera con acceso a tu equipo podría entrar al servidor.

Al terminar tendrás dos archivos: id_ed25519 (clave privada) e id_ed25519.pub (clave pública). Nunca compartas ni subas la clave privada a repositorios, correos o chats. Verifica los permisos con chmod 600 ~/.ssh/id_ed25519 si es necesario.

Cómo copiar tu clave pública al servidor

El método más sencillo es usar el comando ssh-copy-id, disponible en Linux y macOS:

ssh-copy-id [email protected]

Te pedirá la contraseña del servidor una última vez; después, la clave quedará guardada en el archivo ~/.ssh/authorized_keys del servidor remoto.

¿Y si el comando no está disponible? Pasa en Windows, por ejemplo. Entonces copias la clave a mano:

1. Ejecuta cat ~/.ssh/id_ed25519.pub y copia la línea completa que aparece.
2. Conéctate al servidor con ssh [email protected].
3. Edita (o crea) el archivo ~/.ssh/authorized_keys y pega la clave en una nueva línea.
4. Ajusta permisos: chmod 700 ~/.ssh y chmod 600 ~/.ssh/authorized_keys.

Un detalle que no deberías pasar por alto: los permisos incorrectos son la causa más común de que SSH rechace la clave, así que revísalos con cuidado. Para probarlo, abre una nueva terminal y ejecuta ssh [email protected]; si entra sin pedir contraseña, la autenticación por clave ya funciona.

Si tu proveedor de hosting te lo permite, activar este método es una gran mejora de seguridad. En RedServicio, por ejemplo, todos nuestros planes de hosting y VPS incluyen acceso SSH y soporte 24/7 para ayudarte con la configuración si lo necesitas.

Configurar SSH con claves públicas: ajustes en sshd_config

Con la autenticación por clave ya funcionando, toca endurecer el servidor. Todo se hace desde el fichero /etc/ssh/sshd_config. Ábrelo con el editor que uses habitualmente:

1. Ejecuta sudo nano /etc/ssh/sshd_config.
2. Busca (o añade, si no existe) la directiva PasswordAuthentication y ponla en no.
3. Comprueba que tengas PubkeyAuthentication yes.
4. Añade PermitRootLogin no. Así bloqueas el acceso directo de root.
5. Si quieres, limita quién entra con AllowUsers tu_usuario.

Hay otro ajuste que suelo recomendar cuando el servidor está expuesto a Internet: cambiar el puerto con Port 2222 (o el que prefieras). Que nadie se lleve a engaño, no es seguridad en sí mismo. Pero reduce de forma notable los escaneos automatizados, y tus logs dejan de llenarse de basura. Guarda el archivo y reinicia el servicio:

sudo systemctl restart sshd

Verificar el acceso antes de desactivar las contraseñas

Este paso no admite atajos. Desactivar la contraseña sin comprobar antes que las claves funcionan puede dejarte fuera de tu propio servidor. Literalmente. Haz la comprobación en este orden:

• Abre una terminal nueva y conecta con ssh -i ~/.ssh/id_ed25519 usuario@tu_servidor. Si entras sin que te pidan contraseña, la clave funciona.
• Ante la duda, usa el modo detallado: ssh -v usuario@tu_servidor. Fíjate en la línea Authentications that can continue: publickey, que te dice qué método se está negociando.
• Revisa los permisos en el servidor: ~/.ssh debe tener 700 y ~/.ssh/authorized_keys, 600. Es la causa más común de que SSH ignore las claves, y casi nadie lo sospecha al principio. Permisos demasiado abiertos, y el servidor simplemente se niega a usarlas.
• ¿Sigues sin entrar? Mira el log mientras intentas conectar: sudo journalctl -u sshd -f. El mensaje de error suele señalar el problema exacto.

Solo cuando varias sesiones nuevas funcionen sin problemas, aplica PasswordAuthentication no y reinicia el servicio. A partir de ahí, los ataques de fuerza bruta por contraseña dejan de ser un problema. Para siempre.

Conclusión: un servidor más seguro con RedServicio

Pocas mejoras de seguridad dan tanto por tan poco. Al configurar SSH con claves públicas eliminas el vector más explotado (las contraseñas débiles), simplificas tus conexiones de cada día y controlas con precisión quién accede al servidor. El resumen del proceso: generas el par de claves, copias la pública al servidor, verificas el acceso y desactivas la contraseña en sshd_config. Nada más.

¿Gestionas varios servidores? Entonces te interesa el archivo config en ~/.ssh/: ahí puedes definir alias, usuarios y puertos de cada host y dejar de teclear parámetros en cada conexión.

Y si prefieres acompañamiento experto en cada paso, en RedServicio todos nuestros planes de hosting y VPS incluyen acceso SSH completo y soporte 24/7 en español. Nuestro equipo técnico puede revisar tu configuración, ayudarte a implementar las claves y dejarte el servidor protegido sin perder acceso por el camino. La seguridad de tu web empieza por la puerta de entrada. Nosotros te ayudamos a blindarla.