Esiste un modo sicuro per archiviare le password utilizzate per ssh da uno script?

Quindi, prima di tutto, lo so, dovrei usare la chiave auth con SSH. Non c'è bisogno di spiegarmelo.

Il problema qui è che ho un (grande) gruppo di server e ho bisogno che uno script sia in grado di connettere ognuno di questi.

Uso un'autenticazione con chiave ogni volta che posso, tuttavia non è possibile su tutti i server (non ho il controllo su questo). Quindi SSH con login, o talvolta telnet.

Quindi per alcuni ho appena archiviato le password in un db e il mio script va a prenderlo quando necessario. Il problema è che non sembra davvero sicuro farlo in quel modo. C'è un modo per renderlo un po 'più sicuro?

Ti piace un modo specifico per conservarlo?

Se il tuo script può connettersi a uno di quei server, chiunque abbia accesso allo script (o accesso privilegiato alla macchina su cui viene eseguito lo script) può connettersi a uno di quei server.

Se lo script deve essere eseguito in modo autonomo, tutte le scommesse sono disattivate. La risposta qui è no, non esiste un modo assolutamente sicuro per archiviare le password in tale ambiente . Non esiste un modo assolutamente sicuro e pratico di fare qualcosa.

Invece di cercare di evitare l'inevitabile, dovresti concentrarti sulla difesa in profondità .

Sicuramente, ovviamente, dovresti proteggere adeguatamente le password . Questo di solito significa tenerli in un file separato dallo script e configurare le autorizzazioni restrittive del file system . Questo è tutto ciò che puoi fare in questo senso, dal punto di vista della sicurezza.

Altre misure possono sicuramente aggiungere oscurità al processo. La crittografia delle password renderà l'attaccante necessario cercare la chiave di decrittazione. L'uso di una sorta di memoria protetta dal sistema operativo generalmente protegge da altri utenti che accedono alla chiave (quindi non offre alcun vantaggio rispetto alle autorizzazioni del file system, oltre ad essere complesso da attaccare e utilizzare). Queste misure ritarderanno un attacco, ma certamente non lo impediranno contro un determinato attaccante.

Ora, trattiamo le password come pubbliche per un momento. Cosa puoi fare per mitigare il danno?

Una soluzione vecchia e testata è limitare ciò che queste credenziali possono fare. Su un sistema UNIX, un buon modo per farlo è configurare un utente separato per lo script e limitare le capacità di tale utente , sia sui server di accesso che sui server di accesso. È possibile limitare le capacità dell'utente a livello di SSH , a livello di shell o eventualmente utilizzando un meccanismo di controllo dell'accesso obbligatorio come SELinux .

Qualcosa che potresti anche prendere in considerazione è spostare la logica degli script nei server . In questo modo, ottieni un'interfaccia più piccola che è più facile da controllare e soprattutto per ...

Monitor . Monitorare sempre l'accesso ai server. Preferibilmente, autenticazione di registro e comandi eseguiti su un registro di sola aggiunta . Non dimenticare di monitorare le modifiche al file di script utilizzando auditd, ad esempio.

Naturalmente, molti di questi meccanismi non sono utili se non si ha alcun controllo sui server, come sembra implicare la domanda. In tal caso, ti consiglierei di metterti in contatto con le persone che amministrano i server e far loro conoscere il tuo script e le potenziali insidie ​​della sicurezza.

La risposta breve è: No.

La lunga risposta è: No, non esiste un modo completamente sicuro. (Ciò include le variabili di ambiente, a cui gli altri possono accedere sul server.) Il più vicino che puoi ottenere è memorizzarle in un formato crittografato - keepass, un file crittografato con GPG o qualcos'altro lungo quelle linee. Ma a un certo punto devi decrittografare la password in modo che lo script possa usarla, e a quel punto sarai vulnerabile.

In altre parole, è necessario esaminare a fondo la sicurezza approfondita, sia sul server da cui viene eseguito lo script, sia sulla rete che sui server di destinazione.

Potresti crittografare le password nel tuo db con una seconda password e archiviarla su una (terza) macchina separata e disporre di un sistema in cui lo script che deve uscire da una password del db collega prima questa terza macchina per ottenere la password di decrittazione , decodifica la password nel db con la password ottenuta dalla terza macchina e funziona.

Naturalmente questo non aggiunge alcuna ulteriore sicurezza, un attaccante con privilegi sufficienti potrebbe anche richiedere la password dalla terza macchina.

Ma il punto è che una terza parte potrebbe controllare la terza macchina, ad esempio il tuo capo o responsabile della sicurezza, o la terza parte che controlla i server che non controlli.

In questo modo puoi dire loro, se mai hanno un problema, se lasci il tuo lavoro e non si fidano del ragazzo che ti sostituisce, o vogliono solo che i tuoi script smettano di accedere alle loro macchine, possono staccare la spina dal 3 ° macchina e i tuoi script non avranno più accesso alle password.