È una buona idea una posizione centrale per authorized_keys?

Sto configurando un server cloud per eseguire il seguente stack: Ruby, Passenger, Apache; sotto Ubuntu 10.04 (Lucid Lynx).

Nel processo di voler semplificare la gestione del server, ho impostato le chiavi RSA roote www-dataposso sshaccedere al server. La cosa che non mi è piaciuta è stata www-datala .sshdirectory in /var/wwwcui si trova l'impostazione di directory predefinita per apache. La mia preoccupazione è che se apache non è configurato correttamente, la .sshdirectory può essere esposta.

Mi sono imbattuto la soluzione per spostare il ~/.ssh/authorized_keysfile in una posizione centrale, modificando AuthorizedKeysFilein /etc/ssh/sshd_config. Questo viene fornito con 2 professionisti: una posizione unica per le chiavi e non doversi preoccupare di una cattiva configurazione di Apache. L'unico neo che mi viene in mente è che ora ogni utente è disponibile per l'accesso al server (chiaramente un'arma a doppio taglio del file della chiave centrale.)

C'è qualcosa che mi è sfuggito in questa configurazione? Mi sono esposto eccessivamente o è una soluzione migliore dei singoli authorized_keysfile?

Sono verde quando si tratta di gestione dei server, ma sono totalmente pronto per essere chiamato nomi cattivi per fare cose cattive. : D

— Gavin Miller
fonte

Almeno le chiavi pubbliche esposte (sola lettura) su Internet non rappresentano il rischio maggiore ... (Potrebbe consentire agli aggressori di vedere se possono accedere al server con una chiave privata ottenuta altrove, ma non permettere loro di accedere semplicemente ottenendo che ...) (I problemi gravi sono se c'è un id_rsafile ~/.sshe riescono a leggerlo)

— Gert van den Berg,

Risposte:

Tutti i file delle chiavi possono essere centralizzati nella stessa directory e non mescolati nello stesso file.

Basta impostare il sshd_configfile in questo modo:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Sul tuo server:

Le chiavi www-data saranno presenti /etc/ssh/authorized_keys/www-data
saranno presenti le chiavi di root /etc/ssh/authorized_keys/root

Per quanto riguarda i diritti di accesso, queste impostazioni sono accettate da sshd:

/etc/ssh/authorized_keysè di proprietà root:roote ha la modalità 755. I file chiave sono di proprietà root:roote hanno la modalità 644.

Altre modalità potrebbero funzionare ma non le ho ancora testate.

— mahn
fonte

+1, ma non impostarei gli altri bit. Imposta la proprietà dei file% u per l'utente in modo che non sia necessario.

— Aaron Copley,

Buona soluzione al problema che gli utenti malintenzionati possono aggiungere più chiavi pubbliche alle loro chiavi ~ / .ssh / authorized_keys concedendo l'accesso ad altri.

— bbaassssiiee,

Ho appena confermato che la modalità 600 per il file delle chiavi autorizzato di un utente non funziona; deve essere in modalità 644

— Luis E.

@bbaassssiiee Questo ASSOLUTAMENTE NON risolve questo problema. Possono semplicemente condividere la loro chiave privata con chiunque voglia dare accesso (questa possibilità può essere mitigata ovviamente, ma questa risposta fa assolutamente zero per mitigarla)

— DylanYoung

@DylanYoung Ammetto che è possibile condividere le chiavi private. Ma con chattr posso revocare l'accesso in scrittura ai file authorized_keys in modo da poterli distribuire esclusivamente, salvaguardando una sola riga in ogni file.

— bbaassssiiee,

In generale, non farei ciò che stai suggerendo. Infrange ipotesi comuni (come ~/.ssh/authorized_keyslavorare per i tuoi utenti e introduce problemi che hai già menzionato nella tua domanda. Se vedi problemi evidenti prima dell'implementazione significa che la tua soluzione non è l'ideale.

Per quanto riguarda la sicurezza, penso anche che sia un'idea TERRIBILE che tutti condividano un account di servizio: in questo momento sei solo tu, e sai che sei tu a fare le modifiche. Tra 5 anni, quando hai 5 amministratori, vorrai sapere chi ha cambiato cosa e scavare nei registri di controllo per vedere chi ha usato quale chiave quando è un dolore reale.
È meglio avere le persone che accedono come se stesse e usano sudoo qualcosa di simile per intensificare i loro privilegi e fare tutto ciò che devono fare.

Se vuoi ancora centralizzare le chiavi SSH, ti suggerisco di esaminare un sistema di distribuzione come Puppet o radmind per gestire / distribuire i authorized_keysfile nelle ~user/.ssh/directory appropriate (o hackerare una soluzione cresciuta in casa che li metta in posizione).
Quando si espande su più server, è possibile cercare la patch della chiave pubblica LDAP per le versioni precedenti di OpenSSH (o la AuthorizedKeysCommanddirettiva e uno script appropriato nella versione più recente di OpenSSH) in modo da poter centralizzare gli utenti e non dover distribuire le loro chiavi su tutta la rete, ma è probabile che sia abbastanza lontano per te.

— voretaq7
fonte

+1 per l'argomento di condivisione. In breve perché mi ci è voluto un attimo per rendermi conto delle sue implicazioni: non ci dovrebbe essere alcuna directory ~ www-data / .ssh, quindi nessun rischio per la sicurezza dal browser web.

— thiton,

Grazie per il feedback! Se ti sto capendo correttamente. Non dovrei avere rootné www-dataaccessibile tramite un tasto ssh è corretto?

— Gavin Miller,

Avere una ~www-data/.sshdirectory non è una cosa terribile (con le autorizzazioni appropriate non è un rischio sostanziale), ma se hai intenzione di usarlo ~www-data/.sshè probabilmente meglio non avere il tuo webroot ~www-data(o spostare il webroot o spostare www-datala home directory). La differenziazione degli utenti è l'argomento principale di IMHO: so se vedo il jsmithlogin, so che è John Smith. Se vedo il www-datalogin, devo scavare di più per scoprire chi fosse.

— voretaq7,

Il motivo per cui avevo bisogno di una chiave ssh per i dati www è che sto usando Beanstalk (SCM e strumento di distribuzione) per eseguire le distribuzioni su SFTP. Dovrei quindi creare un account separato per Beanstalk per fare l'ftp? Quale sarebbe la migliore soluzione lì?

— Gavin Miller,

Il modo in cui è sulla maggior parte dei sistemi AuthorizedKeysFilein /etc/ssh/sshd_configdefault %h/.ssh/authorized_keys. Ecco %hun segnaposto per la directory home. Cosa ti impedisce di impostarlo /some/folder/ssh_keys_by_user/%h/o addirittura /root/ssh_keys/%u. Si potrebbe anche dare al rispettivo utente l'accesso in scrittura al suo singolo file lì (e solo al suo) collegare il file alla posizione standard (con ln -s /root/ssh_keys_by_user/username /home/username/.ssh/authorized_keys) e non infrangere i presupposti di cui sopra.

— con-f-use