Ho sempre avuto l'impressione che con unix, non dovresti mai accedere come root .
Ora ho iniziato a utilizzare i server privati virtuali all'indirizzo DigitalOcean e alcuni consigli è utilizzare le chiavi SSH per accedere come root.
Questo ha senso per me, ma mi sento a disagio, come se fossi stato sorpreso a usare tab e spazi nello stesso file di testo.
È più sicuro utilizzare l'accesso root SSH o un altro utente con una password complicata?
mricon ha sollevato due punti eccellenti per non utilizzando il login root in un multi -utente sistema. Voglio solo aggiungere un contro-punto per l'utilizzo dell'accesso root. Se ho bisogno di rsync di file di configurazione sul server, posso farlo in un solo passaggio usando il login di root invece di caricarlo nella home directory di un utente, quindi fare di nuovo su o sudo a rsync nel % cartella/etc. Certo, sono l'unico amministratore sul server e il controllo non è un problema qui.
Non esiste una regola dura e veloce per non consentire il login di root. Fa parte di una misura difesa approfondita . A tale scopo, è possibile implementare il filtro IP o il knock-out sul firewall. Questi, insieme a una password strong o all'autenticazione della chiave dovrebbero metterti di buon umore.
La prima regola da ricordare è che non esegui attività come root a meno che non debbano essere eseguite come root.
Questa parte riduce il rischio di danni causati da errori di battitura o altri errori. Riduce inoltre il rischio di danni se gli strumenti in uso presentano una vulnerabilità di sicurezza.
Gli account aggiuntivi dovrebbero avere solo i privilegi di cui hanno bisogno e nient'altro.
Con quelle parti dichiarate, esaminiamo gli argomenti per i due approcci all'accesso root.
Argomenti per l'accesso come non root e usando sudo
Hai una pista di controllo in cui è più facile capire chi ha fatto cosa. Non esegui tutti i comandi come root, ma solo quelli che prefissi con sudo .
Argomenti perché potrebbe non fornirti la stessa sicurezza di chi dice
La pista di controllo funziona solo finché le persone rispettano le regole. È conveniente se ci sono più di due persone con sudo di accesso o se proprio non riesci a ricordare tutto quello che hai fatto tu stesso. Quindi puoi cercare chi ha fatto qualcosa e chiedere loro perché l'hanno fatto.
Ma se qualcuno vuole bypassare la pista di controllo, possono farlo. Se si tenta di impedire a qualcuno di aggirare la traccia di controllo, è probabile che tali restrizioni impediscano loro di svolgere il proprio lavoro.
Le persone possono mettere sudo davanti a ogni comando per riflesso, anche quando non era necessario. E in caso di una vulnerabilità della sicurezza, l'esecuzione senza il comando sudo non ti darà molti vantaggi in quanto se un utente malintenzionato compromette un processo in esecuzione, non importa se è stato eseguito con sudo o meno, perché può solo execve sudo per ottenere gli stessi privilegi.
Argomenti perché usare sudo può essere cattivo
La password utente dà accesso a più privilegi. L'utente può digitare la password dell'utente frequentemente. Se un utente malintenzionato ottiene questa password, può essere utilizzata per eseguire comandi attraverso sudo .
Un account utente compromesso fornisce effettivamente i privilegi di root . Ricorda la parte in cui non si esegue come root a meno che non sia necessario e dando agli account non più privilegi del necessario?
Se si accede come utente non root per tutte le attività che non richiedono i privilegi di root, si riduce l'esposizione. Non ottieni questo vantaggio se l'account ha accesso sudo . Quelle attività che non sono state eseguite come root diventano un obiettivo più prezioso per un utente malintenzionato, se lo stesso account ha accesso sudo .
Che altro puoi fare?
Se si desidera il meglio da entrambi i lati, è possibile assegnare a ciascun amministratore due accessi sul server. Un accesso per le attività quotidiane, che non hanno bisogno dei privilegi di root. E un accesso secondario con sudo di accesso per quando ne ha bisogno. Ma poi l'unica cosa che è diversa tra quel secondo account e il login direttamente come root è la pista di controllo. Ma potrebbe essere più facile per le persone dimenticare che non dovrebbero utilizzare l'account con sudo per tutto il tempo. Ricordare di non accedere come root tutto il tempo sembra un po 'più facile da ricordare per la gente.
E riguardo la forzatura brute delle password?
Alcuni sostengono che è più facile forzare una password per un utente malintenzionato che deve solo indovinare una password e non il nome utente e la password. In realtà questo è un argomento debole.
Puoi configurare sshd per consentire solo accessi utilizzando una chiave. Non è necessario consentire il login utilizzando una password. Se gli accessi alle password non sono consentiti, la forzatura bruta della password non è più un problema. Non c'è nemmeno bisogno di esistere una password, che dia accesso all'account root. E nessuno ha intenzione di indovinare la chiave segreta per l'autenticazione ssh.
Quando /root/.ssh/authorized_keys contiene una chiave pubblica per ciascun amministratore, quelle chiavi pubbliche potrebbero essere utilizzate come traccia di controllo per mostrare chi ha fatto cosa. Ed è altrettanto semplice revocare l'accesso rimuovendo una chiave da authorized_keys come con qualsiasi altro mezzo.
Questa raccomandazione è più pertinente su sistemi in cui più persone possono eseguire operazioni a livello di root. Il daemon di controllo Linux può distinguere "UID" e "UID efficace", quindi l'utente "bob" che esegue "sudo -i" e quindi esegue un'operazione a livello di radice verrà visualizzato nei registri di controllo come "utente bob che agisce come utente root" . Quindi, se segui le modifiche ai file in / etc, o le esecuzioni di file in / sbin, saprai esattamente chi ha eseguito queste azioni. Se qualcuno accede direttamente come root, queste informazioni non saranno disponibili.
Semplifica anche la gestione degli account: se un membro del tuo team di amministratori esce, devi solo bloccare il loro account e non sostituire le chiavi root ssh su tutti i sistemi (sebbene sia comunque una buona pratica, insieme alla modifica delle password di root).
Quello che faccio normalmente è configurare l'accesso all'account root, configurare il server con sudo (aggiungendo me stesso ai sudoers) e quindi non consentire più il login root tramite SSH.
Non vedo un motivo per cui non dovresti essere in grado di lavorare in questo modo, ma dovresti avere un caso valido, usare una chiave e una password è normalmente una buona protezione (è l'autenticazione a due fattori poiché è qualcosa che tu conosci e qualcosa che hai).
Se disabiliti il login di root, diminuisci anche la superficie di attacco della tua macchina. Un altro argomento generalmente dato è che sudo ti dà una certa dose di responsabilità, l'account di root è generalmente un account di sistema e non puoi, se qualcosa o qualcuno accede usando root, sai chi sta effettivamente eseguendo quei comandi. Quando si utilizza sudo si ha ancora quella responsabilità dal momento che la persona deve prima accedere al proprio account e poi sudo per eseguire il root. Questo potrebbe non essere applicabile a te se hai pochi account (e nella maggior parte dei casi non è un sistema di log remoto separato.
Esamino sempre il Digital Ocean quando eseguo il provisioning di un VPS seguendo questi passaggi.
Aggiungi un nuovo utente (comando standard)
Concedi questi nuovi privilegi di root utente eseguendo visudo e aggiungendo il tuo nome utente sotto quello per root nella sezione intitolata "# privilegio utente". Assegna in modo efficace gli stessi privilegi di root
Cambia la porta SSH in ascolto modificando etc / ssh / sshd_config usando il tuo editor di scelta. Individua la linea che dice "Porta 22" e cambia la porzione numerica di quella linea in qualcos'altro. Naturalmente, non utilizzare una porta riservata. Un rapido sguardo online mostrerà quali sono disponibili. Nello stesso file, individua "PermitRootLogin yes" e cambia il "sì" in "no" Come ultimo passaggio, ma farlo con cautela, fornire un accesso esplicito a SSH al tuo nuovo account utente. Ciò richiede l'aggiunta di una riga "AllowUsers"
Dopo tutto questo riavvia il servizio SSH (servizio ssh restart).
NOTA: se non hai accesso alla console per la tua VM / VPS, considera attentamente quanti di questi passaggi cambierai. per esempio. Cambiare semplicemente la porta predefinita è un bene.
Buona fortuna!
Fonte: link
Penso che su un server la raccomandazione "non accedere come root" non sia così difficile. Se sei su un desktop, non usi i privilegi di root più tempo. Ma se si è su un server, la maggior parte del tempo che si usa è un compito di manutenzione. Mentre puoi dare alle persone che devono solo occuparsi degli account limitati del server web, se sei l'amministratore del server, puoi concederti il login di root. La bruteforcing è difficile se si utilizza una chiave per l'accesso root.
Se concedi ad alcuni utenti ALL=(ALL:ALL) ALL -sudo diritti, dovresti eseguire la registrazione su un altro server, in quanto alcuni dei loro comandi potrebbero manomettere i registri.
Grazie a tutti per le risposte, è stato davvero utile. FWIW Sto postando la mia risposta per completezza, che è fondamentalmente l'accesso come utente non root con chiave SSH, disabilitando le password.
È un server VPS a cui solo io ho accesso e che esegue solo un paio di servizi sensibili. A tal fine, voglio che sia il più sicuro possibile con il minor disturbo possibile:
$ adduser demo
authorized_keys in ~/.ssh/
$ visudo demo ALL=(ALL:ALL) ALL
$ vim /etc/ssh/sshd_config
%codice%
PasswordAuthentication no
$ PermitRootLogin no
Speriamo che lo faccia, sicuro accesso SSH senza poteri di root:)
Leggi altre domande sui tag authentication unix ssh