Esiste un modo sicuro per utilizzare una chiave privata da un server condiviso?

Come è stato suggerito, è probabile che l'uso di una chiave di distribuzione di sola lettura sia un approccio utile, e credo che questa sia la soluzione più comune.

Se usi una chiave sul server della tua scuola che ha accesso in lettura / scrittura a github, puoi comunque trasformarla in una chiave che non usi per altro che quell'unico repository, che ne limita il potenziale di abuso.

In alternativa (e meglio), ecco due approcci che evitano i problemi inerenti all'esecuzione del client git sul server non attendibile:

1. A scapito di un maggior numero di ritardi e traffico di rete, è possibile anche eseguire tutta la roba git / ssh dalla propria workstation, mentre si montano i file git repository dal server scolastico, sulla propria workstation, ad esempio utilizzando sshfs. È abbastanza fattibile se sei vicino al server su cui stai lavorando e richiede un minimo assoluto di complessità nella configurazione.

2. Potresti configurare la copia del tuo server scolastico come un altro repository git, al quale avresti accesso tramite ssh. Avresti impostato la copia sul tuo laptop per avere due telecomandi, quindi spingere e tirare da / a github come al solito, e ti spingi sempre a scuola. Usato in questo modo, git è un protocollo di distribuzione molto leggero, probabilmente più leggero di rsync, in quanto non è necessario eseguire la scansione dell'intero albero dei file per le modifiche. Questo sarebbe il mio approccio preferito fintanto che trasformare la copia della scuola in un repository git non è un problema, il che probabilmente dipende anche da chi altro ci sta lavorando.

Considerando la tua spiegazione:

I'm not worried about them seeing the contents of my GitHub repository - I'm concerned about them being about to use the private key to impersonate me and wipe our repo or clone other private repositories that aren't already copied onto the server.

Potresti prendere in considerazione l'utilizzo della funzione GitHub chiamata chiave di distribuzione di sola lettura .

In un ambiente non ostile puoi utilizzare l'inoltro dell'agente SSH , che ti consente utilizzare la chiave sulla macchina client senza la necessità di salvarla su un server springboard, ma questo metodo è sfruttabile dagli amministratori.

Se la macchina che utilizzi come trampolino di lancio è controllata da un amministratore malintenzionato, non è assolutamente possibile proteggere completamente la chiave o il tuo account GitHub.

Fai attenzione che qualsiasi metodo di protezione della chiave che usi, il comando git (che potresti legittimamente eseguire e autorizzare) potrebbe essere sostituito con uno che fa del male.

Indipendentemente dal modo in cui ti avvicini a una domanda del genere, se c'è qualcuno con diritti amministrativi maggiori di te, può esserci assolutamente no way per garantire la completa sicurezza e riservatezza dei dati. Possono guardare i tuoi file, copiarli e implementare un sacco di modi per spiare tutto ciò che fai.

Se ritieni che il tuo account GitHub giustifichi una maggiore sicurezza, dovrai accedervi da una macchina più sicura come il tuo computer.

I am working remotely on a school server via SSH from home. I would like to access a private GitHub repository from the remote system with SSH.

Puoi utilizzare ssh-agent forwarding per risolvere questo problema, senza memorizzare alcun materiale chiave sul server. Questo è il modo preferito e a cosa serve (preferibilmente aggiungendo una chiave all'agente con conferma per ogni azione: -c switch).

If I create a new public/private key pair on the remote system and use a strong passphrase for it, would the system admins, who have sudo access, be able to access and use the private key?

Generalmente, la crittografia delle chiavi ssh è abbastanza buona, ma in teoria, root può scaricare la memoria del processo ssh del tuo cliente o in qualche modo catturare tutto ciò che fai su quel server. L'accesso fisico e root sono cose che non puoi proteggere contro.

Anche se non sono completamente sicuro che un amministratore non possa sfruttarlo.
È possibile limitare almeno il rischio utilizzando l'hardware crittografico appropriato.
(e.a. una smart card (in formato usb)).
Per memorizzare la tua chiave. in questo modo, almeno, sai quando qualcuno ti chiede le tue informazioni chiave.

Inoltre, si limita il tempo a disposizione di chiunque per fare un simile attacco. E devi fare qualche azione per abilitarli.

Aggiunge anche l'ostacolo aggiuntivo di non avere le informazioni sulla chiave principale su uno qualsiasi degli hardware della scuola. (la smart card fa gli importanti bit RSA) e questo è necessario solo nella fase iniziale della connessione, le informazioni chiave che sono presenti nel sistema sono valide solo per quella sessione e non hanno informazioni (sui tasti) che possono essere utilizzato in una data / ora successiva.

2 esempi di tale dispositivo sono:

• il YubiKey
• il Nitrokey