In ogni punto della passphrase - proteggere una chiave privata SSH che viene utilizzata da un account di servizio?

Question

In ogni punto della passphrase - proteggere una chiave privata SSH che viene utilizzata da un account di servizio?

#1 da (11 voti)
#2 da (1 voti)

5

Sulla mia macchina Linux (Alice), sto configurando un account di servizio con un cron run rsync che sincronizzerà alcuni file con un host remoto (Bob). Ovviamente, vorrei rendere sicuro il rsync usando SSH con una coppia di chiavi.

Quindi la mia domanda è: c'è qualche punto nella passphrase - proteggere la chiave privata?

Se io passphrase-proteggi la chiave privata, ovviamente non inserirò la passphrase nello script del cron job. Avrei bisogno di impostare un processo persistente di background ssh-agent in modo che il lavoro cron possa usarlo. Ma allora non sconfigge in qualche modo lo scopo della protezione della passphrase? Se qualcuno può entrare in Alice, non può semplicemente usare il% persistente% co_de per fare tutte le cose cattive di cui hanno bisogno?

L'unico (lieve) vantaggio, credo, è che anche se l'intruso può copiare la chiave privata, non sarebbero in grado di usarlo altrove perché non conoscono la password.

ssh service-account

posta Kal 05.06.2014 - 03:50

fonte

2 risposte

1

Penso che la protezione tramite password sia saggia. Meglio averlo che no. Ma, come hai detto tu, se la macchina di Alice è compromessa, anche con la chiave privata è inutile senza la password. Tuttavia, se la macchina è compromessa, l'autore dell'attacco potrebbe semplicemente aspettare che Alice inserisca la password, e sarebbe facilmente catturata usando un keylogger.

risposta data 05.06.2014 - 04:26

fonte

Leggi altre domande sui tag ssh service-account

Utilizzare BCRYPT per l'hashing della password sul lato client Perché openssl enc -aes-256-cbc -a -salt aumenta le dimensioni del file?

score 11 · Accepted Answer

In questi tipi di scenari, lascio la chiave privata non crittografata (tranne forse seduto su un disco che è crittografato), con le autorizzazioni di lettura limitate a root e il cronjob eseguito come root, ma faccio del mio meglio per limitare l'utilità di questo chiave per il compito molto specifico (rispetto al permettere di accedere al computer remoto con accesso completo).

Questo può essere fatto in modo abbastanza semplice configurando ~/.ssh/authorized_keys per eseguire automaticamente un comando specifico quando si effettua l'accesso utilizzando la chiave specifica.

command="/usr/bin/remote_commands_to_run.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa AAAAB3Nz...DfE= root@some_client

Vedi questa risposta per altro . Dovresti fare attenzione che i comandi in /usr/bin/remote_commands_to_run.sh non permettano a un utente malintenzionato di uscire in una shell. Potrebbe anche aver senso creare un account limitato sul computer remoto con una shell di /bin/false che esegue il comando remoto (ad esempio, inserire la chiave pubblica associata alla chiave privata in authorized_keys dell'utente limitato).

Come sempre dopo averlo configurato, prova e prova per assicurarti che la chiave non abbia più privilegi di quanti ti aspetti (ad esempio, che sftp non funzioni, che rsync non funzioni, ecc.)

A ulteriore avviso, vedo che il tuo compito specifico è quello di rsync dati (presumibilmente in directory specifiche). Questo è probabilmente fattibile con account limitati (ad esempio, chroot'd per essere in grado di vedere solo quelle directory specifiche senza accesso a una shell). Credo che strumenti come rssh possano essere usati per fare questo; consultare il superutente o il server predefinito per il miglior consiglio.

Dato quello che faccio in questo scenario, monto le directory specifiche come unità di rete (ad es. tramite NFS / sshfs) e poi eseguo il rsync nella directory montata in uno script cron.