Claves SSH

Funciones

• Analiza una clave pública: tipo, tamaño, comentario y las opciones de `authorized_keys` del principio de la línea
• ⚠️ Huellas SHA-256 y MD5, idénticas carácter a carácter a la salida de `ssh-keygen -lf`
• ⚠️ Dice claramente que MD5 es el formato antiguo: míralo primero cuando dos valores no coincidan
• ⚠️ El tamaño de RSA se lee del módulo dentro del bloque, no se estima por la longitud del base64
• Las líneas con opciones (`command="echo a b",no-pty ssh-ed25519 …`) no se parten por los espacios
• Genera Ed25519 o RSA 2048 / 3072 / 4096
• ⚠️ La clave privada generada es PEM PKCS#8, con el comando para convertirla a formato OpenSSH (bcrypt_pbkdf no está en un navegador)
• ⚠️ Avisa de que la clave vive solo en la memoria del navegador y se pierde al recargar: cópiala ahora
• Tras generar, vuelve a analizar la clave pública como autocomprobación, para que «generada» y «leída» coincidan
• Todo se ejecuta en tu navegador; las claves no se suben ni se guardan

Cómo se usa

1. Para analizar: pega la línea de la clave pública (cópiala entera de `~/.ssh/id_ed25519.pub`)
2. Para generar: cambia «Qué hacer» a generar, elige un tipo y escribe un comentario
3. Al analizar, compara la línea de la huella con `ssh-keygen -lf` en el servidor

Preguntas frecuentes

¿Por qué hay dos huellas y cuál uso?

Porque son dos representaciones de lo mismo: ambas hacen el hash del binario que decodifica el base64, una con SHA-256 y otra con MD5. Usa SHA-256: `ssh-keygen` lo usa por defecto desde OpenSSH 6.8 (2014), y MD5 no debería usarse para ninguna decisión de seguridad. MD5 está aquí porque muchos servidores, documentos y paneles antiguos aún lo imprimen, y una discrepancia de formato parece «la clave está mal». Cuando no coincidan, mira el prefijo (`SHA256:` o `MD5:`).

¿Por qué la clave privada generada no sirve directamente para ssh?

Porque la clave privada moderna que escribe `ssh-keygen` (`-----BEGIN OPENSSH PRIVATE KEY-----`) usa bcrypt_pbkdf para derivar una clave de cifrado a partir de una frase de contraseña, y ese KDF no está en la API criptográfica del navegador: una página web no puede producirlo. Así que aquí se entrega un PEM PKCS#8 estándar, con el comando `ssh-keygen -p -m pem` para convertirla en el resultado. Fingir que se produce un archivo con forma de `.ssh/id_ed25519` haría creer que basta con copiarlo, y ssh solo daría un error de formato.

¿Qué es esa cadena de opciones antes de la clave en authorized_keys?

Son restricciones sobre la clave y no hay que perderlas al copiar. Las habituales: `command="..."` permite que la clave ejecute solo ese comando (lo típico en claves de despliegue), `from="10.0.0.*"` limita la dirección de origen, `no-pty` prohíbe asignar una terminal y `no-port-forwarding` prohíbe el reenvío. Perderlas amplía la autoridad de la clave a sin restricciones, que es justo lo que se añadieron para evitar.

¿Ed25519 o RSA?

Ed25519, salvo que algo obligue a lo contrario. Es mucho más corta (una clave pública de 68 caracteres frente a más de 500 de RSA 2048), firma más rápido y no tiene los escollos de elección de parámetros de RSA. RSA sigue siendo útil cuando un servidor o dispositivo antiguo no acepta Ed25519; en ese caso usa 3072 bits o más, ya que 2048 se queda corto con los criterios actuales.

¿Son seguras las claves generadas?

La clave sale de `crypto.subtle.generateKey` del navegador, que usa la fuente aleatoria criptográficamente segura del sistema, y es lo bastante fuerte. El riesgo no está en generarla, sino en dónde la guardas: no la subas al control de versiones (un commit la deja en el historial para siempre, borrado incluido), no la pegues en un chat, no la sincronices por la nube. En una máquina de desarrollo puedes borrarla y crear otra cuando quieras: tarda segundos. La clave pública no tiene nada de eso; está hecha para ser pública.