¿Existe una forma segura de usar una clave privada de un servidor compartido?

Como se ha sugerido, es probable que el uso de una clave de implementación de solo lectura sea un enfoque útil, y creo que esta es la solución más común.

Si usa una clave en el servidor de su escuela que tiene acceso de lectura / escritura a github, aún puede convertirla en una clave que no use para nada más que ese único repositorio, lo que limita su potencial de abuso.

Como alternativa (y mejor), aquí hay dos enfoques que evitan los problemas inherentes a la ejecución del cliente git en su servidor no confiable:

1. A expensas de más tráfico y demoras en la red, también puede hacer todo el material git / ssh desde su estación de trabajo, mientras monta los archivos del repositorio git desde el servidor de la escuela, a su estación de trabajo, por ejemplo, utilizando sshfs. Es bastante viable si está cerca del servidor en el que está trabajando y requiere una complejidad mínima en la configuración.

2. Puede configurar la copia del servidor de su escuela como otro repositorio de git, al que accederá a través de ssh. Estableciste la copia en tu computadora portátil para tener dos controles remotos, así que presionas y tiras a / desde github como siempre, y solo presionas a tu escuela. Usado de esta manera, git es un protocolo de implementación muy liviano, probablemente más liviano que rsync, ya que no necesita escanear todo el árbol de archivos para detectar cambios. Este sería mi enfoque preferido siempre que convertir la copia de la escuela en un repositorio git no sea un problema, lo que probablemente también depende de quién más esté trabajando en él.

Teniendo en cuenta tu explicación:

  

No me preocupa que vean el contenido de mi repositorio de GitHub; me preocupa que estén a punto de usar la clave privada para hacerme pasar por mi persona y borrar nuestro repositorio o clonar otros repositorios privados que aún no están copiados en el servidor.

Puede considerar el uso de la función GitHub denominada clave de implementación de solo lectura .

En un entorno no hostil, puede usar reenvío de agente SSH , que le permite use la clave en su máquina cliente sin la necesidad de guardarla en un servidor de Springboard, pero este método es explotable por los administradores.

Si la máquina que utilizas como trampolín está controlada por un administrador malintencionado, no hay forma de que puedas proteger completamente tu clave o tu cuenta de GitHub.

Tenga en cuenta que, independientemente del método de protección de la clave que utilice, el comando git (que podría ejecutar y autorizar legítimamente) podría ser reemplazado por uno que esté haciendo daño.

Sea cual sea la forma en que aborda esa pregunta, si hay alguien con más derechos administrativos que usted, no puede haber ninguna manera para que usted garantice la seguridad y privacidad de sus datos. Pueden mirar sus archivos, copiarlos e implementar muchas formas de espiar todo lo que hace.

Si cree que su cuenta de GitHub justifica una mayor seguridad, deberá acceder a ella desde una máquina más segura, como su propia computadora.

  

Estoy trabajando de forma remota en un servidor de la escuela a través de SSH desde casa. Me gustaría acceder a un repositorio privado de GitHub desde el sistema remoto con SSH.

Puede usar ssh-agent forwarding para resolver esto, sin almacenar ningún material clave en el servidor. Esta es la forma preferida y para qué sirve (preferiblemente agregando una clave al agente con la confirmación de cada acción: -c switch).

  

Si creo un nuevo par de clave pública / privada en el sistema remoto y utilizo una contraseña segura para él, ¿los administradores del sistema, que tienen acceso a sudo, podrán acceder y usar la clave privada?

En general, el cifrado de las claves ssh es bastante bueno, pero teóricamente, root puede volcar la memoria del proceso de su cliente ssh o de alguna otra manera capturar todo lo que hace en ese servidor. El acceso físico y root son cosas contra las que no se puede proteger.

Aunque no estoy completamente seguro de que un administrador no pueda explotarlo.
Puede al menos limitar el riesgo utilizando el hardware criptográfico adecuado.
(p. ej., una tarjeta inteligente (en formato usb)).
Para guardar tu llave en. de esa manera, al menos sabrás cuando alguien te está pidiendo tu información clave.

Además, limita el tiempo disponible para que cualquiera pueda realizar dicho ataque. Y tienes que hacer alguna acción para habilitarlos.

También agrega el obstáculo adicional de no tener la información de la clave maestra en ningún hardware de la escuela. (la tarjeta inteligente realiza los bits RSA importantes) y esto solo es necesario en la etapa inicial de la conexión, la información clave que está presente en el sistema es válida solo para esa sesión y no tiene información (en las claves) que pueda ser utilizado en una fecha / hora posterior.

2 ejemplos de tal dispositivo son:

• la YubiKey
• la Nitrokey