L'accesso come utente condiviso è una cattiva abitudine?

Ho lavorato in organizzazioni in cui invece di creare un nuovo utente Ubuntu per persona che desidera accedere a una macchina, gli amministratori di sistema aggiungono semplicemente la chiave ssh di ciascun utente .ssh/authorized_keyse tutti sshalla macchina come ( ad esempio ) ubuntu@hosto ec2-user@host. (Per inciso, ho anche visto questo praticato su mini Mac condivisi in un ambiente di laboratorio.) È questa pratica accettata o un anti-pattern?

Gli host in questione vengono utilizzati principalmente per i test, ma esistono anche azioni che in genere richiedono la configurazione per utente e vengono monitorate come eseguite da un utente specifico, come la creazione e il push di commit git, che sono attualmente eseguiti usando un git generico utente.

Sì, è una cattiva abitudine. Si basa sul presupposto di base che nessuno è malintenzionato (o sarà) in giro e che nessuno commette errori. Avere un account condiviso rende banale che le cose accadano senza responsabilità e senza alcun limite: un utente che rompe qualcosa lo rompe per tutti.

Se il motivo di questo schema di condivisione degli uid è semplicemente quello di ridurre i costi amministrativi di creazione di nuovi account e condivisione della configurazione, allora forse gli amministratori dovrebbero investire del tempo in un sistema di automazione come Ansible , Chef , Puppet o Salt che crea cose come la creazione di utenti account su più macchine estremamente semplice.

Tanto per cominciare non mi sorprende e lavoro in un ambiente estremamente sicuro. Ognuno ha il suo utente e la sua macchina e la sua chiave ssh, e per lavorare su un server in cui ssh, come root o come un altro utente, attraverso un relay di registrazione, se necessario. Tutto ciò che facciamo viene registrato come fatto dal proprietario della chiave ssh, quindi la responsabilità è OK.

Quale sarebbe l'alternativa? Molte cose devono essere fatte come un certo utente, per non parlare di root. Sudo? Va bene per alcune attività molto limitate, ma non per l'amministrazione della macchina.

Tuttavia non sono sicuro del tuo ultimo paragrafo, vuoi dire che qualcuno potrebbe spingere un git commettere un utente generico? Ciò romperebbe la responsabilità, e rompere la responsabilità è male. Facciamo git dalla macchina in cui siamo loggati e ci autentichiamo per git con la nostra chiave ssh ...

Autenticazione, autorizzazione e contabilità (AAA) è l'espressione classica: sei autenticato con la tua chiave ssh, sei autorizzato a fare tutto ciò che l'utente generico può fare perché la tua chiave è nelle authorized_keys e hai bisogno della contabilità in modo che ciò che fai può essere rivisto dopo il fatto.

Dipende chiaramente dal caso d'uso del sistema. Se di tanto in tanto è un sistema per i test, per me va bene. Abbiamo anche tali sistemi. Se la società non ha alcun tipo di gestione delle identità (LDAP, IPA), creare un nuovo utente senza alcun controllo remoto su un sistema casuale è piuttosto oneroso.

Ma per il lavoro quotidiano quando un errore di qualcuno rende l'intera azienda incapace di operare non è una buona idea.

Tutte queste risposte rispondono alla preoccupazione della responsabilità, che è di per sé un problema importante e reale, ma l'uso di un account condiviso consente anche attacchi non così sottili ad altri utenti:

Considera un utente malintenzionato che crea uno sshscript dannoso che registra la password digitata e la inserisce PATHper quell'utente condiviso (cosa che può essere eseguita facilmente). Ora la prossima persona che accede a quella macchina con l'utente condiviso e decide di trasferirsi in sshun altro posto (questa volta con il suo account personale, non condiviso) potrebbe avere una brutta sorpresa.

Fondamentalmente, usare un account condiviso su un computer è come bere dal pediluvio della piscina pubblica.

In generale, condividere un account è una cattiva idea per i seguenti motivi:

1. Ogni impostazione effettuata per questo utente ha effetto su tutti gli accessi. (Promt, alias, ...)
   2. Perdi la possibilità di scoprire chi ha fatto cosa (responsabilità)
   3. Un errore nella configurazione dell'account (ad esempio l'eliminazione accidentale di ssh kay) riguarda tutti coloro che usano quell'account utente (in quell'esempio bloccare).

E sicuramente ci sono anche altri aspetti negativi ... Ma non voglio approfondire ulteriormente.

Il punto è che potresti trovarti di fronte alla necessità di condividere un account per gestire un servizio eseguito con un determinato account utente a cui tutti gli amministratori dovrebbero poter accedere.

In una configurazione del genere hai la possibilità di condividere questo account per accedere (per quanto sopra, preferirei non farlo) o accedi singolarmente e passi l'utente quindi all'account condiviso (lo suggerirei).

Gli strumenti di controllo ti consentirebbero comunque di tenere traccia di chi ha eseguito cosa ma condividendo comunque lo stesso account.