... give someone a shell in my local net without security risks?

Non

Invece di tentare di limitare l'accesso alla shell di questo utente, consiglierei un approccio completamente diverso.

• Acquista un secondo router
• collega l'Internet del nuovo router alla porta di reg del tuo router esistente
• porta port forwarding 22 dal router esistente al nuovo router
• porta port forwarding 22 dal nuovo router al server
• imposta l'accesso SSH per questo utente non affidabile sul server
• limita il server a twitter / developer / il tuo ip esterno tramite il nuovo router

questo metodo è molto più sicuro / più affidabile di un guscio inverso questo metodo consente allo sviluppatore di utilizzare la tua connessione esterna senza accedere a nulla sulla tua rete (a patto che non sia in grado di sfruttare il nuovo router ... e tu possa monitorare il suo traffico per assicurarti che non stia tentando di hackerarlo) questo metodo non richiede alcuna posizione in testa mentre si batte il campanello per bloccare un ambiente di sviluppo, consentendo allo sviluppatore di svolgere il proprio lavoro.

Detto questo, se sul server ci sono cose che si desidera proteggere da questo utente ... Farei un clone completo del disco rigido del server prima di consentire loro l'accesso ... e poi pulirlo e ripristinare dal backup una volta terminato.

L'accesso fisico è l'accesso root e, sebbene tecnicamente non si conceda l'accesso fisico a questo sviluppatore ... l'accesso alla shell è piuttosto vicino alla stessa cosa. Se un hacker ottiene l'accesso alla shell a un utente non privilegiato ... è prassi comune nuotare dall'orbita ... l'unico modo per essere sicuri.

Tutto ciò è possibile. Vorrei suggerire -

• Crea un utente con autorizzazioni minime. Spiegare tutto questo è al di fuori dello scopo di questo scambio di stack: cercare qualcosa di simile a un errore del server se hai bisogno di aiuto. Ciò diventa più difficile se si desidera limitare l'accesso a file che siano altrimenti leggibili / scrivibili / eseguibili per tutti gli utenti.
• Crea una shell ristretta - vedi qui .
• Assicurati che PAM registri tutto "sessione richiesta pam_tty_audit.so enable = *"
• Per vedere i processi "top -U [username]" o "ps -u [username]".

Tuttavia c'è un grosso problema qui. Pitone. Se l'utente può usare python, possono chiamare eseguibili tramite quello. Si potrebbe tentare di attenuare alcune attenzioni usando qualcosa come PyPy sandboxed .

Dicendo questo dovrebbero comunque avere solo accesso in lettura ai file di sistema e limitati secondo le autorizzazioni degli utenti del sistema operativo. Oltre al solito "assicurati che il tuo sistema sia completamente aggiornato e che non ci siano script / eseguibili eseguiti come utente privilegiato scrivibile da qualsiasi utente" il rischio dovrebbe essere minimo.

Non penso che sia una buona idea. Il modo di farlo è di solito avere una macchina di sviluppo (può essere un vm) e un repository a cui il codice è sottoposto. Questo scenario non richiede alcun accesso al proprio ambiente. Un webserver di sviluppo può essere eseguito con un gig di RAM e un core virtuale. Quindi non costa affatto.

Se ciò non è possibile per una ragione, ci sono alcune opzioni là fuori. Puoi impostare un nuovo vm e metterlo in un vlan separato. Oppure puoi lasciarlo in quel vlan e usare vlans privati per impedire all'host di parlare con qualsiasi altra macchina sul lan a parte il gateway. Puoi anche utilizzare i contenitori per separare l'app.

Se vuoi semplicemente essere in grado di vedere ciò che l'utente ha fatto durante le sessioni, puoi utilizzare un progetto open source chiamato Teleport (vedi gravitazionale / teleport su github ) per fornire loro l'accesso SSH registrato. Registra entrambi gli eventi di controllo e tutto ciò che viene fatto durante le sessioni di shell.

L'ultima versione di Teleport ha una modalità di "proxy di registrazione" in cui, anche se hai fornito root sul nodo del punto finale, tutto ciò che accade durante la sessione verrà registrato dal proxy.