Cómo configurar llaves SSH y GPG para su flujo de trabajo de desarrollo
Hace mucho tiempo, en una galaxia muy, muy lejana, descubrí las llaves SSH y las llaves GPG y pensé que eran buenas … así que comencé a usarlas, obviamente de la manera incorrecta (si quiere saber un poco más, puede iniciar aquí and también aquí). Incluso intenté usar GPG en mi correo electrónico y, como consecuencia, pasé un mes enviando galimatías a todos los demás antes de darme cuenta de lo que estaba sucediendo, porque «El camino al infierno está pavimentado con buenas intenciones», solía decir la abuela.
Hoy en día uso SSH para autenticar conexiones remotas (principalmente a GitHub, y también con algunos servidores) y GPG para firmar los commits de Git, pero configurarlos puede ser pesado, porque involucra muchos comandos de shell que no uso regularmente, así que tengo que buscar todos los pasos, una tarea realmente aburrida, pero luego pensé por qué no juntarlos.
Lo primero que debe hacer, antes de crear llaves, es configurar su nombre de usuario y dirección de correo electrónico en su identidad Git. Esto es importante porque cada commit de Git usa esta información, y está inmutablemente incorporada en los commits que comienza a crear:
$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]
Advertencia: estos datos son «very important», los necesitaremos más adelante para usarlos cuando valide su cuenta de correo electrónico con GitHub y los proporcione en los siguientes pasos.
Ok, con esto fuera del camino, ahora abra su terminal y lo primero que vamos a hacer es verificar si las llaves SSH existentes están presentes, para eso necesitamos enumerar los archivos en su directorio .ssh, si existen:
$ ls -al ~/.ssh
Por defecto, los nombres de archivo de las llaves públicas son uno de los siguientes:
- id_dsa.pub
- id_ecdsa.pub
- id_ed25519.pub
- id_rsa.pub
Si el comando muestra una lista vacía, eso significa que tenemos que crear un nuevo par. Para eso debemos ejecutar el siguiente comando en nuestra terminal:
$ ssh-keygen -t rsa -b 4096 -C "[email protected]"
Cuando se le solicite, recomiendo seleccionar las opciones predeterminadas, así que solo presione intro. Y no olvide usar una buena contraseña para su llave. Todo este proceso crea un nuevo par de llaves ssh, utilizando el correo electrónico proporcionado como etiqueta y la mejor codificación disponible en la actualidad. Ahora solo nos falta agregar el nuevo par de llaves al agente ssh, primero debemos ejecutarlo en segundo plano (solo esta primera vez en caso de que no se ejecute automáticamente) usando el comando:
$ eval "$(ssh-agent -s)"
Esto arroja el PID del agente, que muestra que está funcionando, y ahora, dado que usó esto como su nombre y ubicación para su par de llaves, podemos ejecutar el siguiente comando:
$ ssh-add ~/.ssh/id_rsa
Ahora solo necesitamos agregar nuestras llaves a nuestro repositorio de código, supongo que GitHub, pero si no, usar otro no es tan difícil, por lo que en el futuro no tendremos que pasar por el proceso de autenticación HTTP habitual cada vez. Para agregar las llaves a nuestra cuenta de GitHub, necesitamos copiar el contenido de la llave pública a nuestro perfil, para eso ejecuta el siguiente código:
$ cat ~/.ssh/id_rsa.pub
Dado que utilizó los valores predeterminados en el paso anterior, esto imprime el contenido del archivo en su terminal, cópielo en su portapapeles. Ahora vaya a la pantalla de configuración en su cuenta de GitHub.
Seleccione la pestaña de llaves SSH y GPG y complete los campos con datos descriptivos (para que sepa lo que está viendo después de un año), y agregue su nueva llave SSH a la cuenta. Con esto fuera del camino, ahora podemos crear las llaves GPG usando la herramienta GPG; si no las tiene, puede descargar las herramientas de línea de comando GPG de su página de descarga GnuPG.
Primero revisemos la lista de llaves GPG existentes para las que tiene una llave pública y una privada:
$ gpg --list-secret-keys --keyid-format LONG
Si no hay pares de llaves GPG o si no desea utilizar ninguna disponible para firmar commits y etiquetas, deberá generar una nueva llave GPG. Pero si hay un par de llaves GPG existentes y desea usarlas para firmar commits y etiquetas, entonces solo tendrá que agregar su llave GPG a su cuenta de GitHub e informar a su Git local al respecto.
Para generar una nueva llave, ejecutemos el siguiente comando y tengamos en cuenta las siguientes consideraciones:
$ gpg --full-generate-key
- Para el tipo de llave que desea, le recomiendo presionar Intro para aceptar el RSA y RSA predeterminado.
- Para el tamaño de la llave, asigne el tamaño máximo de la llave de 4096.
- A menos que tenga una necesidad específica, presione Enter para indicar que la llave no caduca.
Verifique que sus selecciones sean correctas. - Cuando se le solicite ingresar su dirección de correo electrónico, use la que verificó para su cuenta de GitHub.
- Siempre use una frase de contraseña segura, como debería.
Ahora que tenemos nuestro nuevo par de llaves GPG, tenemos que hacer dos cosas: necesitamos decirle a Git sobre ellas, para que podamos comenzar a firmar nuestros commits, y luego debemos decirle a GitHub -o su proveedor de elección para eso- que importe su llave, para que puedan validar los commits.
Primero llamamos a las llaves usando el siguiente comando:
$ gpg --list-secret-keys --keyid-format LONG
Ahora copie la ID de llave GPG que le gustaría usar. En este ejemplo, la ID de la llave GPG es 3AA5C34371567BD2 y debería arrojar algo como:
/Users/hubot/.gnupg/secring.gpg sec 4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10] uid Hubot ssb 4096R/42B317FD4BA89E7A 2016-03-10
Ahora ejecutemos el siguiente comando, sustituyendo la ID de llave GPG que desea usar de su lista:
$ gpg --armor --export 3AA5C34371567BD2
Este comando imprime la llave GPG en formato de armadura ASCII, solo necesita copiar su llave GPG, comenzando con —– BEGIN PGP PUBLIC KEY BLOCK —– y terminando con —– END PGP PUBLIC KEY BLOCK —–. Para esto solo necesitamos repetir los pasos que seguimos para agregar las llaves SSH, esta vez usaremos la sección a continuación para la llave GPG, y en el campo «Key», pegamos nuestra llave GPG previamente copiada del terminal.
Et voila, le dijimos a GitHub sobre sus llaves GPG y SSH, y ahora solo necesitamos decirle a Git sobre nuestra llave GPG, para esto repetimos el comando para enumerar nuestras llaves:
$ gpg --list-secret-keys --keyid-format LONG
Eso debe mostrarnos algo como esto:
/Users/hubot/.gnupg/secring.gpg ------------------------------------ sec 4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10] uid Hubot ssb 4096R/42B317FD4BA89E7A 2016-03-10
Y luego podemos ejecutar el siguiente comando, sustituyendo el ID de llave GPG que queremos usar:
$ git config --global user.signingkey 3AA5C34371567BD2
Y ahora Git también conoce nuestras llaves porque usted, querido desarrollador, acaba de asignarlo a su identidad de Git, y está sincronizado con su cuenta remota (GitHub en mis ejemplos, pero debería ser bastante fácil de hacer con otros servicios como BitBucket y GitLab).
Pero espera, ¿por qué la gente debe firmar sus commits? ¿Solo porque algún tipo al azar (uno realmente guapo e inteligente si me dejas señalarlo) en Internet lo dijo? La respuesta es no, deberíamos firmar nuestros commits porque cuando yo, como desarrollador, firmo un commit de Git, puedo probar que yo fui quien envió un fragmento de código, y que ese fragmento no se modificó en la transferencia. Tenga en cuenta que esto no se trata de la caza de brujas y el desarrollador afilando sus horquillas, en realidad, ¿pueden afilarse? Buscando a alguien a quien culpar por los errores (pero ciertamente también puede hacerlo si lo desea).
Desarrolladores del mundo, firmar los commits de Git es importante en esta era de código malicioso y puertas traseras, ayuda a protegerlo de un atacante que de otra manera podría inyectar código malicioso en su base de código. También ayuda a disuadir a los desarrolladores no confiables de agregar sus propias puertas traseras al código, porque una vez que se descubre, el código incorrecto se remontará a ellos.
