~sergio

ARTIGOS

Por qué e cómo: Cambiar de RSA a EdDSA/ED25519 nas chaves SSH

12-09-2023

É bastante probable que como programador teñas as túas propias chaves SSH para conectarte ós servidores, ou polo menos para conectar co servidor git. Hoxe en día é bastante raro teclear o teu usuario e contrasinal para enviar os últimos cambios ó repositorio remoto. Normalmente, esas chaves son xeneradas usando o algoritmo RSA, o cal foi e sigue sendo o estándar para xenerar chaves criptográficas.

Si non che interesa o por qué e queres ir directamente ó tutorial, salta aquí directamente.

Por que o RSA non che vai ir ben para as seguintes décadas

Cando se inventou no 1977, o RSA parecía a mellor solución para xenerar chaves seguras. Os ordenadores eran lentos e levaríalles décadas ata que o RSA se volvera inseguro debido o crackeo do algoritmo. Ahora, avanzando 40 anos, esas chaves non son realmente seguras si a súa lonxitude é de menos de 1024 bits. Desde o 2013 a ENISA (European Union Agency for Cybersecurity) recomenda o uso de chaves con unha lonxitude de 2048 bits para unha seguridade a corto plazo. Polo tanto: non xeneres claves novas de menos de 4096 bits de largo!

Así e todo, un pode argumentar que símplemente usando chaves máis largas solucionaríase o problema, xeneramos chaves de 8192 bits e listo. O problema con esto é que o tempo para procesar chaves deste tamaño non é adecuado para dispositivos de baixa potencia, mentras que a seguridade ganada non se incrementa proporcionalmente: unha chave de 1024 bit para unha chave asimétrica (a que se usa para SSH) solo ten unha forza «real» de 80 bit basandose en métodos simétricos. Incrementando a lonxitude de 1024 a 2048, sin embargo, non incrementa a seguridade «real» a 160 sinon solo a 112 bit.

Entra en escena: Algoritmos de Curva Elíptica

Para resolver o problema de que as claves largas conlevan tempos de procesamento moito máis altos mentras que solo aumentan a seguridade un pouco, algunha xente realmente intelixente descubriron os algoritmos basados en curvas elipticas. Tristemente, eu non sei explicar como funcionan esos constructos matemáticos. Basándome na información dispoñible, esas curvas elípticas pódense usar para xenerar chaves fortemente seguras mentras se manteñen máis cortas que as chaves RSA. Por exemplo, unha chave cunha lonxitude de 256 bits é igual de segura que un AES de 128 bits que equivale a unha chave de 3072 bits de largo. Desta maneira chaves mais cortas, con unha seguridade maior que o RSA, son máis fáciles de procesar en máquinas pouco potentes.

A criptografía de curvas elípticas é solo a teoría, na que se basan EdDSA (Edwards-curve Digital Signature Algorithm) e ECDH (Elliptic-curve Diffie–Hellman). Mentras que EdDSA é o esquena criptográfico, ED25519 é a implementación para xenerar chaves SSH. Polo tanto, ED25519 úsase para xenerar as chaves e ECDH como protocolo de intercambio. Hai outro algoritmo para xenerar chaves chamado ECDSA que foi creado para reemplazar o RSA. Desafortunadamente, a implementación non se considera segura, así que é definitivamente mellor usar as chaves ED25519 no seu lugar.

Visto esto, podemos concluir que cambiar de RSA a ED25519 é unha boa idea. E si sabes que a tua chave RSA ten solo 1024 bits de largo, cambiaa o antes posible!

Como cambiar de RSA a ED25519

Antes de cambiar, un consello: o seguinte proceso pode levar un anaco, dependendo do número de servidores ós que te conectes e donde teñas almacenadas as chaves públicas. Tamén, faite un favor e fai unha copia de seguridade ahora mesmo tos teus arquivos id_rsa e id_rsa.pub. Copiaos a un directorio de backups dentro to teu directorio ~/.ssh ou copiaos a un pendrive USB, o que che pareza mellor pero garda esos arquivos seguros en todo momento.

Feito? Sigamos...

Xenerar unha chave ED25519 nova

Xenerar a chave basada no ED25519 é o primeiro paso. O seguinte comando é un exemplo e deberías adaptalo ó teu gusto:

ssh-keygen -t ed25519 -b 521 -C "manolo@exemplo.com" -f ~/.ssh/exemplo.com

Especificando unha contrasinal

Durante a execución do comando anterior vaiche pedir que especifiques unha contrasinal. Por favor, non te saltes isto. En numerosos blogs e tutoriales están de acordo con saltarse este paso pero...

NON TE SALTES A CONFIGURACION DA CONTRASEÑA!

Configurar unha contraseña é o mesmo que establecer unha para a túa conta de correo electrónico. Si un atacante o outra persoa aleatoria ten acceso ó arquivo que contén a túa chave privada, poderaa usar sin ningún tipo de obstáculo! E con acceso á tua chave privada terá acceso a tódolos servidores nos que a teñas configurada. Así que, por favor, ponlle unha contraseña. E no mellor dos casos, ponlle unha igual de forte que calquera outra que xeneres. Usa un maldito xestor de contrasinais si non queres ter que acordarte das claves.

Despóis de que establezas a clave, o xenerador fará a súa maxia. Noraboa, ahora eres o orgulloso propietario de unha nova chave ED25519! A salida do comando debería ser algo similar a esto:

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/sergio/.ssh/exemplo.com
Your public key has been saved in /home/sergio/.ssh/exemplo.com.pub
The key fingerprint is:
SHA256:hkAlmuVVoVsij+y08QIYxukmhyC/o57yGsK2EiMdY8g manolo@exemplo.com
The key's randomart image is:
+--[ED25519 256]--+
|    +.o.o.       |
|. .* o .         |
|==o + o .        |
|*E+. = =         |
|+=+o= + S        |
|B..= + .         |
|+=o + .          |
|=oo. .           |
|**.              |
+----[SHA256]-----+
Subindo a nova chave ós teus servidores

Por suposto, agora querás subir a túa nova chave a tódolos servidores que usas (eu prefiro ter chaves diferentes para diferentes servidores, por eso o parámetro -f no comando anterior, pero cada un ó seu gusto). Asumindo que os servidores ós que te conectas teñen un mínimo de seguridade e están actualizados a día de hoxe ou así, o que significará que teñen a última versión do OpenSSH ou de un servidor SSH similar. Si o teu servidor non soporta ED25519, terás o traballo de actualizar o servidor.

O comando máis sinxelo para subir a chave SSH ó teu servidor xa ven preinstalado con OpenSSH:

ssh-copy-id -i ~/.ssh/exemplo.com [usuario]@[servidor]

Especificando a clave de usuario (-i ~/.ssh/exemplo.com) e as túas credenciais SSH ([usuario]@[servidor]), o comando debería copiar automáticamente a túa clave pública ó servidor. Proba a conectarte ó servidor usando a chave nova para comprobar si funciona correctamente:

ssh -i ~/.ssh/exemplo.com [usuario]@[servidor]

Verás que no servidor, no arquivo ~/.ssh/authorized_keys" estará agregada a clave pública. Unha maneira manual de configurala é copiando o contido da clave pública e pegalo a man neste arquivo.

Non te esquezas de que tamén podes agregar a tua clave pública a outros servicios online como por exemplo ó teu servidor git.

Configura SSH para que use a túa nova chave

Por último, queremos que o SSH use a nova clave sin ter que especificala. O principal problema é que o SSH intenta usar por defecto unha clave RSA chamada id_rsa. Pero nós queremos que use a nova ED25519 e non esa cousa vella chamada RSA. A mellor maneira de facelo é usando o arquivo de configuración. Outras maneiras son un pouco «hacks» máis que soluciós. Si non usas xa o arquivo de configuración SSH, normalmente está en ~/.ssh/config. En ese arquivo podes especificar configuraciós globales que se aplicarán a tódalas conexiós, ou configurar host a host.

Así que abre o .ssh/config ahora. E si queres usar a chave nova para tódalas conexiós SSH copia o seguinte arriba de todo:

Host *
    IdentityFile ~/.ssh/exemplo.com

A primeira liña indícalle que aplique esa configuración a tódolos hosts, de ahí o comodín *. A segunda liña dille qué arquivo usar de identidade.

Por outro lado, xa comentei que eu prefiro ter unha chave por servidor así que a chave creada sería para acceder ó servidor «exemplo.com» quedando da seguinte maneira o arquivo .ssh/config:

Host exemplo.com
    IdentityFile ~/.ssh/exemplo.com

Tendo así varias chaves para diferentes servidores quedaría algo así o noso arquivo ~/.ssh/config, xenerandoas con nomes adecuados, claro:

Host exemplo.com
    IdentityFile ~/.ssh/exemplo.com

Host foo.net
    IdentityFile ~/.ssh/foo.net

Host sbc.bar.org
    IdentityFile ~/.ssh/sbc.bar.org

E eso é todo, non ai moito máis que configurar. Ahora poderás acceder ós servidores sin ter que especificar a clave e recorda que si non os tes agregados no ~/.ssh/config teras que especificala co «-i path/key».

Conclusión

A pesar de quedar un post algo largo, básicamente son unhos poucos comandos para crear a chave e logo subila ó servidor SSH e por último configurar o SSH para que use a nova chave. Dependendo da cantidade de servidores que teñas pódeche levar 10 ou 20 minutos. Despóis de rematar xa poderás seguir coa túa chave SSH super segura.


NOTA: Este post é unha traducción libre e adaptación de este outro de Kevin Woblick.