with - ¿Dónde almacenar el token de acceso personal de GitHub?

remote: you must use a personal access token with ''api'' scope for git over http.

Question

¿Es necesario almacenar el token de acceso personal en algún lugar localmente en la máquina después de generarlo en GitHub?

En caso afirmativo, ¿hay alguna forma preferida de almacenarlo?

Answer 1

La mitad de las contraseñas es que (idealmente) las memoriza y el sistema las pulsa, por lo tanto, nunca se almacenan en ningún lugar en texto plano.
Sin embargo, ¿el sistema de token de acceso personal de GitHub parece básicamente obligarlo a almacenar el token en texto sin formato?

Primero, un help.github.com/articles/… no es una contraseña simple, sino un equivalente que:

• puede generar varias veces (por ejemplo, una por máquina desde la que necesita acceder al repositorio de GitHub)
• se puede revocar en cualquier momento (desde la interfaz web de GitHub), lo que hace que PAT sea obsoleto, incluso si permanece en una de esas máquinas.

Eso difiere de su contraseña, que es exclusiva de su cuenta, y no se puede cambiar fácilmente sin tener que modificarla en cualquier lugar donde la use.

Dado que se puede usar un PAT en lugar de una contraseña al realizar operaciones de Git a través de HTTPS con Git en la línea de comandos o la API, puede usar un asistente de credenciales de git para almacenarlo en caché de forma segura.
En Windows, por ejemplo, eso usaría el Administrador de credenciales de Windows , a través del GCM (Administrador de credenciales de Git) para Windows :

git config --global credential.helper manager

La primera vez que presiona para obtener un repositorio, una ventana emergente le pedirá sus credenciales: nombre de usuario y su PAT.
La próxima vez, no preguntará, y reutilizará directamente ese PAT, que permanece almacenado de forma segura en su Administrador de credenciales.

Una idea similar se aplica a Mac con el llavero OSX , y a Linux con el anillo de claves de GNOME .
La idea sigue siendo: almacenar el PAT en un almacén de credenciales cifradas .

Answer 2

Básicamente hice esto en mi máquina:

https://gist.github.com/bsara/5c4d90db3016814a3d2fe38d314f9c23

Mi script de perfil es ligeramente diferente al descrito:

env=~/.ssh/agent.env
agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; }
agent_start () {
(umask 077; ssh-agent >| "$env")
. "$env" >| /dev/null ;
}
agent_load_env
# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)
if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
agent_start
ssh-add
elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
ssh-add
fi
unset env

Answer 3

Bueno, tienes que guardar el token en algún lugar , cuando no quieras escribirlo cada vez que tu aplicación lo solicite :-)

Una buena solución es utilizar variables de entorno, como ya se sugirió en un comentario .

Pero todavía tienes que establecer la variable de entorno en algún lugar.
En Windows (que estoy usando), podría usar el cuadro de diálogo en la configuración del sistema (no sé si otros sistemas operativos tienen algo similar) .

Yo no hago esto, prefiero un script en mi proyecto.
En un proyecto privado, puede comprometerse con el control de código fuente, pero esto es una cuestión de preferencia.

En uno de mis proyectos personales, también llamo a la API de GitHub, usando un token de acceso personal.
Es una aplicación de línea de comandos y el usuario final guardará el token en un archivo de configuración (que está bien) .

Pero también necesito el token para el desarrollo, porque el proyecto tiene pruebas de integración donde llamo a la API de GitHub.

Y ese proyecto es público en GitHub, así que no pude guardar el token en el control de código fuente.

Lo que hice es esto:

• Tengo un archivo de proceso por lotes (recuerde que estoy en Windows) llamado environment-variables.bat que establece todas las variables de entorno necesarias, incluido el token de acceso
• Llamo a esto en mi script de compilación y en el archivo por lotes que estoy usando para ejecutar mis pruebas
• environment-variables.bat se ignora en el control de origen
• Pero en el control de origen, hay environment-variables.bat.sample lugar, que contiene el mismo, pero un token / contraseña falso.

Así que solo puedo cambiar el nombre de este archivo a environment-variables.bat , reemplazar la contraseña falsa por la real, y todo funciona.

Sin embargo, esta no es la solución perfecta para todos los casos.

En mi proyecto, tengo el problema de que necesito usar más tokens / contraseñas para más API en el futuro.

Por lo tanto, la cantidad de tokens en mi environment-variables.bat aumentará, lo que dificultará que los contribuyentes potenciales realicen todas las pruebas de integración. Y todavía no sé cómo lidiar con eso .

Answer 4

Me gusta mantenerlos cifrados dentro del repositorio y cargarlos usando .envrc ( https://direnv.net/ )

Para hacer esto, uso ssh-vault para cifrar los datos usando mis claves ssh que GitHub ya está exponiendo , por ejemplo:

echo MY_TOKEN="secret" | ssh-vault -u <github-user> create > my-encypted-vars.ssh

Entonces el contenido de .envrc ve algo como esto:

echo "Enter ssh key password"
context=$(ssh-vault view $HOME/projects/my-encrypted.ssh | tail -n +2)
export ${context}

Esto descifrará los datos en my-encrypted-vars.ssh y establecerá MY_TOKEN en mis variables de entorno cada vez que cd en el directorio del proyecto.

Al hacer esto, los tokens / variables se almacenan "de forma segura" y siempre están listos para usar como variables de entorno