Repositorios - Jusaba/Domo-Serverpic GitHub Wiki
En Serverpic, para deposito de los repositorios vamos a utilizar gitub
Partimos de que tenemos una cuenta creada, en nuestro caso, tenemos una cuanta denominada jusaba.
Para la gestión de git en local nos hemos decantado por Sourcetree.
En los siguientes apartados se va a detallar como crear un repositorio en la cuenta de github y como se va a enlazar con sourcetree para ir actualizando el repositorio desde calquier ordenador pero antes, es necesario unos pasos previos de configuración.
Antes de incluir cualquier repositorio, lo primero que debemos hacer es decir a SourceTree que vamos a enlzar con Github por SSH, para ello, el menu, en la opcion Tools, seleccionamos Create or import SSH Keys, se nos abre PuTTY Key Generator
En el Menú Key Seleccionamos SSH-2 RSA key, luego, pulsamos el botón Generate y movemos el raton por la zona vacia hasta que finaliza el proceso de generación.
Salvamos la clave publica y privada dando a los botones correspondientes en c:/Users/NuestroUsuario/.ssh
Ahora, debemos registrar la clave publica en GitHub para que SourceTree pueda acceder, para ello, en Github , accedemos a Settings en el menu de usuario
Vamos a SSH and GPG keys y añadimos una clave nueva con New SSH key
Le ponemos un titulo a la clave y copiamos la información relejada en la ventana Public Key... de PuTTY en la ventana Key de Gitub
Pulsamos Add SSH key y ya está incorporada la clave publica en Github
Por último, tenemos que decir a SorcTree que debe utilizar SSH para comunicarse con Github y hay que indicarle donde está la calve privada que debe utilizar ( la generada y salvada con PuTTY en un paso anterior). Para este paso, debemos ir a la opcion Options del menú Tools. En la pestaña General en el apartado SSH Client Configuration indicaremos donde se encunetra la clave e indicaremos que es un cliente Putty/Plink
Con esto ya tenemos establecido la consxión SSH entre SourceTree y Github y pasamos a crear y sincronizar nuestro primer repositorio.
Actualmente, la aplicación de escritorio de GitHub es mucho mas sencilla de manejar que SorcTree por lo que desde Octubre del 23 dejamos de utilizar SorcTree y pasamos a Github Desktop Ahora ya no nos serviran las claves generadas con PuTTY Key Generator por que ssh-agent de windows no reconoce el formato. Generamos nuevas claves de la siguiente forma
En el direcotrio C:\Users<Usuario>\.ssh teclear
ssh-keygen -t rsa
Nos preguntara nombre y si queremos password, en el nombre ponemos por ejemplo Git para identificar los ficheros
Esto generará un par de claves Publica/Privada
Git
Git.pub
Para activar estas claves , tenemos que registrar la clave publica en GitHub tal como se detallo en SorcTree, añadiendo una nueva clave ssh en el menú y copiando el contenido de Git.pub.
En el terminal de windows tendremos que agregar la clave privada a ssh-agent. Es posible que el servicio este desactivado por lo que lo primero que se ha de hacer es activarlo, para ello en Servicios de windows debe ponerse OpenSSHy Autthentication Agent en inicio automatico y desde PowerShwll teclear:
Start-Service ssh-agent
Ahora ya, desde una ventana *CMD escribir:
ssh-add C:\Users\<Usuario>\.ssh\Git
Con eso se añadirá la clave privada ssh-agent y ahora Github Desktop ya podrá operar con GitHub sin problemas.
Podemos comprobar que ssh-agent ha registrado la clave tecleando
ssh-add -l
Para ilustrar como funciona ssh-agent se ha extraido esta explicación de la pagina https://juncotic.com/ssh-agent-que-es-y-como-funciona/
Primero que nada hay que aclarar un punto importante: las claves públicas y privadas de SSH están destinadas a autenticar al usuario, NO a cifrar el contenido del tráfico.
Desde el punto de vista del servidor SSH, el protocolo funciona de la siguiente manera (muy breve y resumido):
El cliente le da su clave pública.
El servidor genera un mensaje denominado Key Challenge, y lo envía al cliente para realizar la verificación de identidad.
El cliente usa la clave privada para realizar la verificación, y responde al servidor.
El servidor constata la veracidad del Key Challenge del cliente.
El servidor ahora sabe que el cliente es quien dice ser y establece el túnel.
Luego de esto se generan claves simétricas efímeras para el intercambio de tráfico cifrado.
Ahora bien, cuando decimos que el cliente usa su clave privada para generar la firma, en realidad «pide» al ssh-agent la firma del mensaje, y el ssh-agent, que tiene acceso a la clave privada, lo firma y la devuelve.
Aquí es donde radica la fortaleza del protocolo cuando se hace uso de ssh-agent: el servicio SSH deja de estar en contacto directo con las claves privadas, que pasan a estar gestionadas por un servicio independiente.