È sempre meglio mettere authorized_keys nella propria directory .ssh piuttosto che nella directory .ssh di root? [duplicare]

Sicurezza vuoi che le persone usino sudo non su (Sudo può essere configurato in modo che registri tutte le attività, a.k.a. un registro di controllo).

ulteriori informazioni sulla maggior parte degli accessi * nix root a ssh sono proibiti (impostazione nel file delle impostazioni che raccomanderei di abilitare). questo è per impedire che un SSH (-server) violato possa essere utilizzato per l'accesso ROOT.

Ulteriore sicurezza che raccomanderei è usare chiavi crittografate (e tu hai una password che devi inserire per il tuo tasto non il tuo prompt di accesso) e usare un agente per condividere le tue chiavi pubbliche. Altrimenti tutto ciò di cui ho bisogno è la chiave memorizzata per accedere, rimuovendo 1 delle soglie di sicurezza.

inoltre, limita sudo (e su ) utilizza solo per le attività di amministrazione del sistema (e solo per quelle attività che non puoi fare altrimenti) usa groups per l'accesso condiviso non root .

Mi spingerò anche a raccomandare di usare chiavi diverse per connessione (non riusare le chiavi in particolare la chiave id_rsa) e usare .ssh / config per impostare quale chiave usare quando.

- > Chiarificazione aggiuntiva per le "chiavi diverse"

Il motivo per cui usi chiavi diverse è che hai una sicurezza a più livelli, rende più facile revocare una chiave e sostituirla (e non "dimenticare" un vecchio server che ti blocca da quella) e se lo fai per client e connessione hai la stessa opzione su entrambe le estremità.

Soprattutto se controlli più di pochi server questo può diventare un problema a lungo termine. per alcuni sistemi ho persino più di 1 chiave per separare le autorizzazioni e l'autorizzazione (con più "zone di sicurezza" sul server con chiavi diverse (che hanno password diverse) in modo che quella con accesso in scrittura non sia uguale a quella con shell l'accesso.

Un altro punto che vorrei fare è che è sempre meglio usare il minor numero possibile di permessi. Quindi, invece di usare su per accedere come root, usa su per diventare un utente diverso (quello con i permessi di scrittura nella cartella comunque, come www-data su ubuntu per le cartelle httpd di apache) piuttosto che fare la tua cosa, e se davvero ho bisogno di usare più permessi (cambiare i permessi e installare le applicazioni sono per lo più per me) usa "sudo [operazione] (opzioni)" invece di solo sudo su. non solo lascia questo registro di controllo più pulito, ma limita anche possibili errori (scrivendo nella posizione sbagliata, scrivendo i file come root quando dovrebbero essere di proprietà del server web, ecc.) e richiede che tu sappia cosa stai facendo. invece di andare "hey, ha funzionato come l'ultima volta".

"Sudo su" è come rimuovere un muro con una bomba. rimuove il muro, ma una semplice mazza potrebbe aver fatto lo stesso (con meno danni collaterali possibili).

Si tratta di gestire un rischio, come con tutte queste cose.

Se fai di routine tutto come root, suggerirei che è il tuo problema, piuttosto che il meccanismo di login. Perché? Bene, perché stai facendo tutto con il massimo livello di privilegio.

Questo suggerisce che non hai impostato le tue autorizzazioni e ACL in modo appropriato. Idealmente nessuno dovrebbe ever "funzionare come root" - e semplicemente privilegiare l'escalate di tanto in tanto per eseguire comandi che richiedono tale privilegio.

Il login diretto come root sembra piuttosto un punto controverso, specialmente se non è necessario eseguire nuovamente l'autenticazione per sudo su .

Personalmente suggerirei di non farlo e invece:

• usa sudo per i singoli comandi quando ti servono.
• funziona normalmente come "tu".
• imposta le autorizzazioni che consentono a "tu" di fare le cose che ti servono.

E limita l'attività root che stai facendo.

Ci sono davvero solo pochi benefici per la sicurezza che posso pensare offerti dall'accesso come se stessi e dall'uso di sudo e dall'accesso come root.

• I percorsi di controllo sono disponibili se non sei l'unico amministratore sulla macchina (se sei l'unico amministratore, questo non si applica affatto)
• Devi inserire la tua password per elevare a root con sudo, che fornisce una protezione marginale contro il compromesso chiave (questa non è una vera sicurezza, un avversario intelligente potrebbe semplicemente fare qualcosa come cambiare il PATH in. bashrc e crea il proprio script "sudo" che salva la tua password al prossimo accesso). Questo vantaggio non si applica affatto se sudo è configurato per l'accesso senza password.
• Hai più protezione se esci da una sessione SSH aperta senza bloccare la tua console (se lo fai, revocherò la tua licenza sysadmin).

Secondo me, la ragione principale per cui la maggior parte delle persone consiglia di accedere con un normale account utente e di elevare a root per le attività di amministrazione del sistema non è solo quella di proteggerti dagli aggressori, è di proteggerti da te stesso La barra extra in avanti di rm -rf è molto meno pericolosa in esecuzione come te che come root). Personalmente, se non mi aspetto di eseguire attività non di root su una macchina, non mi preoccuperò nemmeno del normale account utente - lo eliminerò e useremo root (solo).

Se sei paranoico e vorresti veramente beneficiare della protezione extra fornita da sudo, aggiungerei due chiavi SSH. Creane uno per root e installalo in /root/.ssh/authorized_keys e creane uno per il tuo utente normale. Modifica / etc / sudoers per consentire al tuo account normale di eseguire attività specifiche che devono essere eseguite come root su una base di routine. Per tutto il resto, assicurati che l'appartenenza al gruppo ti consenta di eseguire le attività che devi eseguire. La normale chiave utente va sul tuo computer. La chiave radice va su un'unità flash o una smart card / token in una cassastrong antincendio. Il compromesso è convenienza (come sempre), ma se pensi davvero di aver bisogno di una maggiore sicurezza, questo è un modo per farlo (non l'unico modo, solo quello che mi è venuto fuori di testa).