Generador de Claves SSH

RSA de 2048 bits cumple con los estándares de seguridad actuales y está aprobado por el NIST hasta al menos 2030. RSA de 4096 bits ofrece un margen de seguridad mayor para claves que estarán en uso durante muchos años, pero es significativamente más lento para las operaciones de saludo (aproximadamente 4 veces más lento que 2048 bits). Para la mayoría de los casos de uso — acceso a servidores, GitHub/GitLab, pipelines de CI/CD — 2048 bits es suficiente. Para claves utilizadas en entornos de alta seguridad o que se espera que estén en uso durante más de 10 años, usa 4096 bits. Para la mejor combinación de velocidad y seguridad, usa Ed25519 en su lugar.

Una frase de paso cifra tu archivo de clave privada para que, incluso si alguien obtiene el archivo, no pueda usarlo sin la frase. Cuando usas la clave, tu cliente SSH te pide la frase de paso para descifrarla (ssh-agent puede almacenar en caché la clave descifrada para que no tengas que introducirla repetidamente). Para claves orientadas al usuario (de tu portátil a tus servidores), usa una frase de paso: proporciona una protección crítica si tu máquina se pierde o es robada. Para claves de despliegue automatizado en CI/CD que se ejecutan sin interacción humana, las claves protegidas por frase de paso son poco prácticas y el archivo de clave debe asegurarse por otros medios (permisos de archivo, sistemas de gestión de secretos).

Copia el contenido de la clave pública (que comienza con "ssh-rsa" o "ssh-ed25519") y adjúntalo al archivo ~/.ssh/authorized_keys en tu servidor. Una clave pública por línea. Si el directorio no existe: mkdir -p ~/.ssh && chmod 700 ~/.ssh. Establece los permisos correctos: chmod 600 ~/.ssh/authorized_keys. El método más rápido desde tu máquina local: ssh-copy-id user@hostname (usando tu contraseña para esta configuración de una sola vez). Después de eso, SSH usará tu clave automáticamente. Tu clave privada permanece únicamente en tu máquina local y nunca se sube a ningún lugar.

El comentario es una etiqueta incrustada en la clave pública después de los datos de la clave (por ejemplo, ssh-ed25519 AAAA... user@laptop). No tiene ningún efecto en la autenticación; es puramente descriptivo. Úsalo para identificar el origen de la clave cuando revises authorized_keys en un servidor: quién creó esta clave, desde qué máquina y con qué propósito. Formatos comunes: user@hostname (por defecto), tu dirección de correo electrónico o una etiqueta descriptiva como "ci-deploy-prod-2026". Cuando tienes varias claves en authorized_keys, un comentario significativo es la forma en que sabes qué clave revocar si algo sale mal.

La huella es un hash SHA-256 de la clave pública, mostrado en formato Base64 (por ejemplo, SHA256:abc123...). Es una forma compacta de identificar y verificar una clave específica. Cuando te conectas por primera vez a un servidor con SSH, el servidor te muestra su huella de clave de host; tú la verificas para confirmar que te estás conectando al servidor correcto. Cuando subes una clave pública a GitHub, GitLab u otros servicios, ellos te muestran la huella. Si la huella coincide con la que muestra esta herramienta, la clave se subió correctamente. También puedes ejecutar ssh-keygen -l -f ~/.ssh/id_ed25519 en tu máquina para verificar las huellas localmente.

Sí. Toda la generación de claves utiliza la Web Crypto API, que es una API nativa del navegador que proporciona operaciones criptográficamente seguras respaldadas por la fuente de entropía del sistema operativo. La generación de números aleatorios utiliza crypto.getRandomValues(), no el inseguro Math.random(). Las claves generadas son equivalentes en seguridad a las producidas por ssh-keygen en la línea de comandos. No se envía nada a ningún servidor: el par de claves existe únicamente en tu sesión del navegador.

Nunca reemplaces tus actuales authorized_keys; adjunta tu nueva clave pública como una entrada adicional. Luego, abre una segunda sesión SSH (sin cerrar la actual) para probar la nueva clave. Solo después de confirmar que la nueva clave funciona deberías eliminar las claves antiguas o cambiar tu política de contraseñas. Si te quedas fuera, necesitarás acceso a la consola del servidor (los proveedores de la nube llaman a esto "emergency console" o "rescue mode") para editar manualmente authorized_keys.