🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Proteger el acceso SSH en Syspanel con claves públicas

Actualizado el 4 de junio de 2026

¿Por qué deberías usar claves públicas en Syspanel?

Cuando gestionas un servidor, el acceso SSH es la puerta principal. Si esa puerta solo tiene una contraseña, es como dejar la llave puesta por fuera. Los ataques de fuerza bruta son constantes en Internet: bots que prueban miles de combinaciones por minuto. La solución más efectiva y estándar en la industria es usar claves públicas SSH, un método criptográfico que elimina por completo la necesidad de contraseñas.

En este artículo te explicaré paso a paso cómo configurar la seguridad SSH Syspanel usando claves públicas SSH. Aprenderás a generar tu par de claves, copiarlas a tu servidor y desactivar el acceso por contraseña. Todo explicado de forma sencilla, sin tecnicismos innecesarios, para que lo hagas tú mismo aunque seas nuevo en esto.

¿Qué es una clave pública y una clave privada?

Imagina que tienes una caja fuerte con dos llaves: una llave pública que puedes repartir a quien quieras y una llave privada que jamás sale de tu ordenador personal.

La llave pública se instala en tu servidor (en Syspanel). La llave privada se queda en tu equipo local. Cuando intentas conectarte, el servidor te lanza un desafío matemático que solo tu llave privada puede resolver. Si coincide, te deja entrar. Sin contraseñas, sin riesgo de que alguien las adivine.

Este sistema se llama acceso remoto seguro y es el estándar en empresas de hosting y administración de sistemas.

Requisitos previos

Antes de empezar, asegúrate de tener:

  • Acceso a tu servidor con Syspanel (puerto 2106 para el panel).
  • Una cuenta de usuario con permisos de administrador (root o sudo).
  • Un ordenador local (Windows, macOS o Linux) desde el que te conectarás.
  • Ganas de aprender, ¡nada más!

[INFO] Si aún no tienes Syspanel instalado, este artículo te servirá igualmente para cualquier servidor Linux con SSH. Syspanel es el nombre que usamos aquí para referirnos al panel de control, y su acceso web es por el puerto 2106.

Paso 1: Generar tu par de claves SSH

Lo primero es generar las claves en tu ordenador local. No en el servidor. Esto es muy importante: las claves privadas nunca deben generarse ni almacenarse en el servidor.

En Windows (PowerShell o CMD)

Abre PowerShell y escribe:

ssh-keygen -t ed25519 -C "tu-correo@ejemplo.com"

En macOS o Linux

Abre la terminal y escribe el mismo comando:

ssh-keygen -t ed25519 -C "tu-correo@ejemplo.com"

[TIP] Si tu sistema no soporta ed25519 (muy raro hoy en día), usa -t rsa -b 4096.

El comando te preguntará dónde guardar la clave. Pulsa Enter para aceptar la ubicación por defecto (~/.ssh/id_ed25519).

Luego te pedirá una frase de contraseña (passphrase). No la dejes vacía. Aunque parezca un paso extra, esta frase protege tu clave privada si alguien roba tu ordenador. Es tu segunda capa de seguridad.

¿Qué acabas de generar?

Dos archivos:

  • id_ed25519: tu clave privada. No la compartas jamás.
  • id_ed25519.pub: tu clave pública. Esta es la que irá al servidor.

Paso 2: Copiar la clave pública a tu servidor

Ahora toca llevar la clave pública a tu servidor. Hay dos formas: con un comando automático o manualmente.

Opción A: Usar ssh-copy-id (recomendada)

En macOS o Linux, escribe:

ssh-copy-id usuario@tu-servidor-ip

Te pedirá la contraseña de tu usuario. Una vez la introduzcas, la clave se copiará automáticamente al archivo ~/.ssh/authorized_keys del servidor.

Opción B: Copia manual

Si usas Windows o prefieres hacerlo a mano:

  1. Muestra el contenido de tu clave pública:
cat ~/.ssh/id_ed25519.pub
  1. Copia todo el texto que aparece.

  2. Conéctate a tu servidor por SSH con tu contraseña normal.

  3. Ejecuta estos comandos:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
  1. Pega tu clave pública, guarda con Ctrl+O, Enter, y sal con Ctrl+X.

  2. Fija los permisos correctos:

chmod 600 ~/.ssh/authorized_keys

[WARNING] Si los permisos de ~/.ssh o authorized_keys no son correctos, SSH rechazará tu clave. Asegúrate de que .ssh tenga 700 y authorized_keys tenga 600.

Paso 3: Probar la conexión con tu clave

Antes de desactivar nada, prueba que la conexión con clave funciona.

Desde tu ordenador local:

ssh usuario@tu-servidor-ip

Si todo está bien, entrarás sin que te pida contraseña. Si te pide la frase de contraseña de tu clave privada, escríbela (es la passphrase que pusiste al generar la clave, no la contraseña del servidor).

[INFO] Si usas Syspanel, recuerda que el acceso al panel web es por el puerto 2106, pero SSH sigue usando el puerto 22 por defecto. No los confundas.

Paso 4: Desactivar el acceso por contraseña

Una vez confirmado que entras con tu clave, es hora de cerrar la puerta a las contraseñas. Este es el paso que realmente convierte tu servidor en un acceso remoto seguro.

  1. Conéctate a tu servidor por SSH.

  2. Abre el archivo de configuración de SSH:

sudo nano /etc/ssh/sshd_config
  1. Busca (o añade si no existe) la línea:
PasswordAuthentication yes

Cámbiala a:

PasswordAuthentication no
  1. Guarda con Ctrl+O, Enter, y sal con Ctrl+X.

  2. Reinicia el servicio SSH:

sudo systemctl restart sshd

[WARNING] No cierres la sesión actual hasta probar que puedes volver a entrar con tu clave. Si algo falla, te quedarías fuera. Abre una segunda terminal y prueba la conexión antes de cerrar nada.

Paso 5: Configuración adicional recomendada

Para llevar la seguridad SSH Syspanel al máximo, te recomiendo estos ajustes adicionales en el mismo archivo sshd_config:

Cambiar el puerto SSH por defecto

El puerto 22 es el más atacado. Cambiarlo reduce drásticamente los intentos de fuerza bruta.

Port 2222

Elige un puerto alto (entre 1024 y 65535). Recuerda abrirlo en el firewall.

Desactivar el acceso root por SSH

Es más seguro usar un usuario normal y elevar privilegios con sudo.

PermitRootLogin no

Limitar usuarios que pueden conectarse

AllowUsers usuario1 usuario2

Solo esos usuarios podrán acceder por SSH.

Establecer un tiempo de espera

ClientAliveInterval 300
ClientAliveCountMax 2

Así se cortan las sesiones inactivas.

[TIP] Después de cada cambio, reinicia SSH y prueba desde otra terminal antes de cerrar la sesión actual. Es la regla de oro.

Solución de problemas comunes

"Permission denied (publickey)"

Esto significa que tu clave no se está aceptando. Revisa:

  • Que la clave pública esté en ~/.ssh/authorized_keys del servidor.
  • Que los permisos sean correctos (700 en .ssh, 600 en authorized_keys).
  • Que estás usando el usuario correcto.

"Connection refused"

El servicio SSH no está corriendo o el puerto no está abierto. Verifica el firewall.

"Host key verification failed"

Es un mensaje de seguridad. Si has reinstalado el servidor, elimina la clave antigua de tu archivo known_hosts:

ssh-keygen -R tu-servidor-ip

Olvidé mi passphrase

No hay recuperación. Tendrás que generar un nuevo par de claves y repetir el proceso. Por eso es importante que guardes tu passphrase en un gestor de contraseñas.

[WARNING] Si pierdes tu clave privada y desactivaste las contraseñas, no podrás entrar al servidor. Guarda una copia de seguridad de tu clave privada en un lugar seguro, como una unidad cifrada.

Preguntas frecuentes

¿Puedo tener varias claves públicas?

Sí. Cada línea en authorized_keys es una clave distinta. Útil si te conectas desde varios dispositivos.

¿Qué pasa si quiero revocar una clave?

Simplemente elimina la línea correspondiente del archivo authorized_keys. Deja de funcionar al instante.

¿Es seguro usar la misma clave en varios servidores?

Es aceptable, pero si un servidor se compromete, todas tus claves están en riesgo. Mejor genera una por servidor.

¿Syspanel usa SSH para algo más?

Syspanel (panel de control) se gestiona por el puerto 2106 vía web. El SSH es independiente. La seguridad SSH Syspanel protege el acceso al sistema operativo, no al panel.

¿Puedo volver a activar las contraseñas?

Sí. Solo cambia PasswordAuthentication de vuelta a yes y reinicia SSH. Pero no lo hagas salvo que sea estrictamente necesario.

¿Qué es mejor, ed25519 o RSA?

ed25519 es más moderna, rápida y segura. Úsala siempre que puedas. RSA de 4096 bits es la alternativa si necesitas compatibilidad con sistemas antiguos.

Conclusión

Configurar claves públicas SSH en tu servidor Syspanel es una de las medidas más efectivas que puedes tomar para proteger tu infraestructura. El proceso es sencillo una vez que lo entiendes, y los beneficios son enormes:

  • Eliminas el riesgo de ataques de fuerza bruta.
  • Ya no dependes de contraseñas que puedan filtrarse.
  • Accedes más rápido, sin escribir nada.
  • Tienes control total sobre qué dispositivos pueden conectarse.

La seguridad SSH Syspanel no es un lujo, es una necesidad. Cada día se registran millones de intentos de acceso no autorizado. No dejes la puerta abierta.

Si has seguido todos los pasos, tu servidor ahora es mucho más difícil de vulnerar. Y recuerda: la seguridad es un proceso, no un destino. Revisa periódicamente tus claves, rota las que ya no uses y mantente al día con las buenas prácticas.

[TIP] Programa una copia de seguridad de tus claves privadas en un lugar cifrado. Tu yo del futuro te lo agradecerá cuando cambies de ordenador.

¿Tienes dudas o problemas con algún paso? Repasa el artículo con calma y verifica cada punto. La mayoría de los errores vienen de permisos incorrectos o de copiar mal la clave. Con paciencia, lo conseguirás.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel