Claves SSH explicadas
La autenticación por clave SSH es la forma de entrar en un servidor sin contraseña: en lugar de escribir un secreto que el servidor pueda comprobar, tu ordenador demuestra que posee una clave privada firmando un desafío que envía el servidor, y el servidor verifica la firma con la clave pública que ya tiene archivada. La clave privada nunca cruza la red, así que no hay nada que interceptar, nada que pescar con phishing y nada que adivinar. Este artículo explica cómo funcionan las dos mitades de un par de claves, qué tipo de clave elegir en 2026, cómo las huellas detienen a un intermediario en tu primera conexión, cómo mantener limpios authorized_keys y known_hosts, y exactamente qué hacer cuando se filtra una clave. Para generar, inspeccionar o convertir una clave en tu navegador, usa la Suite de claves SSH, y para comprobar las contraseñas que aún usas, la Comprobación de filtración de contraseñas.
Qué es la autenticación por clave SSH
Cada inicio de sesión es una pregunta que hace el servidor — ¿eres quien dices ser? — y una contraseña la responde entregando el secreto mismo. Esa es la debilidad de todo el arreglo: el secreto viaja, puede ser escuchado, puede ser reproducido y puede ser adivinado, intento tras intento, hasta que cae. La autenticación por clave SSH cambia la respuesta. En lugar de enviar el secreto, tu ordenador firma un desafío aleatorio del servidor con una clave privada que nunca sale de tu máquina, y el servidor comprueba la firma con la clave pública guardada en tu archivo authorized_keys. La prueba es nueva cada vez, porque el desafío es aleatorio; el secreto nunca aparece en el cable, así que un oyente no aprende nada que pueda reutilizar, y no hay contraseña que adivinar, porque no hay ninguna contraseña en juego.
La idea es más antigua que el internet moderno — la criptografía de clave pública data de los años setenta — pero SSH la convirtió en la forma cotidiana de llegar a un servidor, y el protocolo la ha llevado desde entonces. Cuando ejecutas ssh usuario@servidor, el cliente y el servidor acuerdan una sesión, el servidor presenta un desafío vinculado a tu cuenta, y tu agente SSH lo firma con la clave privada, normalmente después de que desbloqueas la clave una vez con una frase de contraseña. Si la firma se verifica, entras. Nada del intercambio depende de un secreto compartido que el servidor también conozca, y por eso una brecha del servidor no expone tus credenciales: el servidor solo tiene claves públicas, y una clave pública es inútil para entrar. Esa asimetría — el servidor puede verificar pero no puede suplantar — es todo el argumento de seguridad de las claves, y también es la razón por la que perder el control de la mitad privada es el único fallo que importa.
La clave pública y la clave privada
Un par de claves son dos mitades con reglas opuestas, y la mayoría de los errores de SSH vienen de tratarlas igual. La clave pública está hecha para copiarse en todas partes: pégala en authorized_keys de cada servidor que uses, en tu cuenta de alojamiento de Git, en cualquier servicio que acepte claves SSH. Se puede publicar en un repositorio público, imprimir en una diapositiva o enviar por correo a un administrador, porque todo lo que permite hacer a cualquiera es verificar una firma. Conocer tu clave pública no le da a un atacante nada con lo que entrar, del mismo modo que conocer tu número de casa no le da a nadie la llave de tu puerta. La mitad pública es una cerradura, no una llave, y las cerraduras están hechas para verse.
La clave privada es la llave misma, y su regla es exactamente la opuesta: nunca sale de tu máquina, solo tú puedes leerla, y nunca debe pegarse en un chat, un ticket, un correo, una publicación en un foro o un documento compartido — ni siquiera para preguntar si es segura. Quien la tenga puede entrar como tú en cada servidor que confíe en la clave pública correspondiente, sin que aparezca ninguna solicitud de contraseña ni ningún segundo factor, a menos que hayas configurado uno. En el disco vive en ~/.ssh, protegida por permisos de archivo — chmod 600, solo lectura y escritura del propietario — e idealmente por una frase de contraseña, que cifra el archivo para que una copia robada siga siendo inútil sin las palabras que lo desbloquean. La frase de contraseña no forma parte de la clave; es un candado en la caja donde está la llave. Pierde la caja y el candado es lo único que se interpone entre el ladrón y tus servidores, y por eso una clave privada sin frase de contraseña nunca debe salir de una máquina que controlas por completo.
Ed25519 frente a ECDSA y RSA: cuál elegir en 2026
En 2026 la respuesta predeterminada es Ed25519, y es la predeterminada que genera este sitio. Ed25519 es una clave de curva elíptica de 256 bits: se genera en una fracción de segundo, firma rápido y produce una clave pública que cabe en una sola línea corta. OpenSSH la admite desde 2014 y todos los servidores y clientes actuales, y su seguridad descansa en una curva diseñada en abierto sin constantes sospechosas. No hay ninguna razón práctica para elegir otra cosa para una clave nueva, a menos que algo de tu entorno te obligue. Si te quedas con una sola recomendación de este artículo, que sea esta: genera Ed25519, pon una frase de contraseña y sigue adelante.
Los otros tipos existen para las excepciones. ECDSA en las curvas NIST P-256 o P-384 es la opción correcta donde la política exige curvas NIST — algunos entornos regulados y tokens de hardware antiguos las especifican — y es un buen recurso si un navegador o dispositivo no puede generar Ed25519. RSA sigue siendo el recurso universal: RSA 2048 es el mínimo que merece la pena usar, RSA 3072 o 4096 la opción cuando el otro lado no puede usar curvas elípticas en absoluto, lo que hoy significa sobre todo sistemas muy antiguos y unos pocos dispositivos embebidos. Todo lo inferior a RSA 2048 — RSA 1024, DSA, ssh-dss — es legado y debe retirarse: la Suite de claves SSH lo marca como débil por exactamente esa razón. El tamaño de la clave no lo es todo, sin embargo: una clave RSA de 4096 bits copiada a un portátil que ya no posees es peor que una clave Ed25519 de 256 bits bien guardada, porque el modo de fallo de las claves SSH casi nunca es la matemática. Es el archivo.
Huellas y la primera conexión
La primera vez que te conectas a un servidor, SSH te muestra algo que parece una cadena aleatoria de caracteres y te pregunta si confías en ella: 256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ. Esa cadena es la huella de la clave de host del servidor — un hash de la clave pública del servidor — y es lo único que se interpone entre tú y un intermediario. Si la huella coincide con la que publicó tu administrador, o con la que verificaste por un canal aparte, entonces la máquina que responde es realmente el servidor al que querías llegar. Si no coincide, detente: alguien puede estar interceptando la conexión, o el servidor puede haber sido reconstruido con una clave nueva, y en cualquier caso lo seguro es comprobar antes de escribir yes. Esa solicitud es SSH haciendo su trabajo más importante, y las personas que se meten en problemas son las que se entrenan a escribir yes sin leerla.
Puedes verificar una huella antes de conectarte, con ssh-keygen -lf, que imprime una línea por clave: el tamaño en bits, la huella, el comentario y el tipo de clave entre corchetes, por ejemplo 256 SHA256:… [email protected] (ED25519). La Suite de claves SSH imprime las huellas exactamente en este formato, así que un valor que ves en el navegador se puede comparar carácter por carácter con lo que muestra el servidor. Una vez que aceptas una clave de host, SSH la guarda en ~/.ssh/known_hosts y te advierte en voz alta — negándose a conectar — si alguna vez cambia. Esa advertencia no es una molestia que se sortea con una opción; es la alarma sonando. La única excepción rutinaria es un servidor reconstruido legítimamente, en cuyo caso el administrador debería haber publicado la nueva huella con antelación, y tú eliminas la entrada antigua con ssh-keygen -R nombredehost antes de volver a conectar.
Higiene de authorized_keys y known_hosts
Cada línea del archivo authorized_keys de un servidor es una puerta, y las puertas siguen abiertas mucho después de que la persona que las necesitaba se haya ido. El portátil de un contratista, un trabajo de integración continua, una clave generada en una máquina que ya se ha borrado, un colega que cambió de equipo hace dos años: cada una es una línea que sigue funcionando, y cada una es una credencial que ya no vigilas. La auditoría es sencilla y merece la pena cada pocos meses: copia el archivo, pégalo en la pestaña Inspeccionar de la Suite de claves SSH y mira lo que devuelve. Los duplicados — la misma clave pública dos veces — significan que alguien pegó una clave de nuevo en lugar de comprobar, y deben reducirse a una línea. Las entradas débiles — RSA por debajo de 2048, DSA, ssh-dss — deben eliminarse y sustituirse. Y cualquier línea cuyo comentario nombre a una persona, una máquina o un propósito que ya no reconoces debe tratarse como una puerta que cerrar hasta que su dueño pueda reclamarla.
known_hosts merece la misma atención desde el otro lado. Registra la clave de host de cada servidor al que te has conectado, y SSH comprueba cada conexión nueva con ella. Algunas entradas están con hash — |1| seguido de base64 — lo que oculta el nombre del host, una función de privacidad para portátiles que podrían perderse o ser inspeccionados; la Suite de claves SSH notifica esas entradas como con hash en lugar de fingir que son legibles, porque una entrada con hash no se puede verificar con una huella publicada, solo confiar en ella como ya aceptada. El archivo en sí también es evidencia: un known_hosts lleno de servidores que ya no usas es un mapa de dónde han estado tus credenciales, y podarlo no cuesta nada. Juntos, los dos archivos son el registro completo de tu confianza SSH en ambas direcciones — quién puede entrar como tú, y en qué máquinas confías para ser ellas mismas — y ambos se pudren en silencio si nadie los mira.
Cuando se filtra una clave — y la nota sobre la frase de contraseña
Una clave filtrada no es un misterio que investigar primero y sobre el que actuar después; es una clave que hay que sustituir, y el orden de las operaciones es corto. Genera un par de claves nuevo. Elimina la clave pública antigua de authorized_keys en cada servidor y cada servicio: tus servidores, tu alojamiento de Git, tus pipelines de despliegue, cualquier lugar donde se instaló la clave. Luego comprueba a qué podía llegar la clave antigua y busca cualquier cosa fuera de lugar: líneas nuevas en authorized_keys que no añadiste, inicios de sesión en horas en las que no trabajabas, procesos desconocidos. Si encuentras algo, trátalo como una brecha, no como un susto, e investiga a partir de ahí. Lo que no debes hacer es borrar la clave privada antigua de tu portátil y considerar el trabajo hecho: borrar tu copia no hace nada con las copias que se filtraron, y la clave pública que sigue en authorized_keys sigue siendo una puerta que funciona.
Una frase de contraseña no cambia esta lista, pero cambia la urgencia con la que la ejecutas. Una clave protegida con frase de contraseña que se filtra como archivo sigue siendo un problema — un atacante puede intentar adivinar la frase sin conexión, a velocidad de máquina — pero una frase fuerte te compra el tiempo para rotar antes de que la adivinanza tenga éxito. Una clave sin cifrar no te compra ningún tiempo, y por eso este sitio es franco sobre lo que produce su generador: la versión 1 genera claves sin cifrar, sin opción de frase de contraseña, porque el KDF bcrypt de OpenSSH para claves privadas cifradas es trabajo de la versión 2. Si generas una clave aquí, protege el archivo con chmod 600 y añade una frase de contraseña en tu propia máquina con ssh-keygen -p: lleva diez segundos, convierte el archivo en su lugar, y es el hábito de mayor valor de todo este artículo. Genera la clave, pon la frase de contraseña, instala solo la mitad pública, audita los archivos dos veces al año y verifica cada huella antes de confiar en ella: esa es toda la disciplina, y cabe en una tarjeta.