Come consentire a ssh di eseguire il root dell'utente solo dalla rete locale?

Ho installato Google-Authenticator su una macchina CentOS 6.5 e configurato alcuni utenti per fornire OTP.

Durante la modifica /etc/ssh/sshd_configho visto una direttiva " PermitRootLogin" che è commentata per impostazione predefinita.

Vorrei impostare " PermitRootLogin no" ma essere ancora in grado di eseguire lo ssh sulla macchina come root solo dalla rete locale.

È possibile?

linux ssh centos6

— Itai Ganot
fonte

Non farlo mai. SSH come utenti, quindi usa sudo per elevare le autorizzazioni. Fallo in modo che lasci una scia di carta e così saprai quale account è stato compromesso.

— SnakeDoc,

@SnakeDoc: Questa è una scuola di pensiero, ma non è chiara e direi il contrario. sudo è un'enorme superficie di attacco complessa e non qualcosa che avrei mai voluto installare. L'autenticazione pubkey SSH è una superficie di attacco molto più piccola. Entrambi possono essere registrati, ma la registrazione non è molto utile quando l'utente (root) può modificare o eliminare i registri, il che è sempre il caso, a meno che non si acceda a un archivio esterno di sola aggiunta.

— R ..

@R .. Se hai impostato correttamente i sudoer, usando il principio del privilegio minimo, questi problemi che hai descritto non sono in gran parte un problema. Nessun utente dovrebbe essere in grado di eseguire lo ssh in e il sudo - suroot, o fare qualsiasi cosa i loro utenti non abbiano bisogno (nei sudoer, usi la white list per i comandi). Se hai bisogno di root, devi essere fisicamente sulla console, ad es. Il root su SSH non dovrebbe mai essere permesso ... chiavi o no.

— SnakeDoc,

@SnakeDoc: ti sbagli. Sudo ha entrambe le proprie superficie di attacco complesse, e superficie di attacco complesso fondamentale che è inerente ad essere un binario suid, in forma di tutti lo stato che è applicata all'intera execve. In alcuni casi non è nemmeno necessario un bug nel programma stesso (suid); i bug nell'infrastruttura sottostante come il linker dinamico (ad esempio CVE-2010-3856) possono essere sufficienti.

— R ..

@R .. Supponi di sapere sempre se una chiave è trapelata. Questo è un diavolo di un'ipotesi. Inoltre, una volta entrato, il tuo attaccante ha i privilegi di root. È ancora meglio inviarli attraverso un account senza privilegi e farli elevare alla radice. In questo modo hai una chiave che deve essere trapelata, una passphrase chiave da rompere e quindi una normale password dell'account utente da rompere. E se l'attaccante riesce a superare tutto ciò ... non può fare nulla perché questo utente è impostato su sudoer con capacità molto limitate ... Vedi i vantaggi ora? Non consentire l'accesso diretto alla radice nel periodo ssh ... È una buona igiene

— SnakeDoc il

Risposte:

Utilizzare il Matchparametro config in /etc/ssh/sshd_config:

# general config
PermitRootLogin no 

# the following overrides the general config when conditions are met. 
Match Address  192.168.0.*
    PermitRootLogin yes

Vedere man sshd_config

— Sven
fonte

Perché non ci ho pensato? Grazie

— amico

Puoi anche limitare l'origine per le chiavi di autenticazione ~root/.ssh/authorized_keys. Prefisso la chiave con from="192.168.0.0/24 ".

— BillThor,

Lo cambierei per consentire anche gli indirizzi IPv6 link-local. Il modo in cui funzionano gli indirizzi link-local in IPv6 li rende molto robusti per le reti configurate in modo errato. Ciò significa che se è necessario ssh per correggere una configurazione errata della rete, è possibile che l'uso di un indirizzo di collegamento IPv6 locale sia l'unica opzione rimasta.

— Kasperd,

Cordiali saluti Se usi anche la direttiva AllowUser , devi farlo anche (e controintuitivamente)AllowUser root

— Robert Riedl il

Il Match addressmetodo è già stato menzionato, ma puoi anche limitare gli utenti (o gruppi) a cui è consentito accedere a un sistema. Ad esempio, per limitare gli accessi all'utente itai(da qualsiasi luogo) e root(da una rete specifica), utilizzare:

AllowUsers itai root@192.168.0.*

Ciò impedisce a tutti gli altri utenti (come apache) di accedere tramite SSH.

Vedi anche la AllowUsersparola chiave nel manuale sshd_config (5) .

— Lekensteyn
fonte

Preferisco AllowGroupse aggiungo tutti gli utenti che dovrebbero essere in grado di accedere tramite SSH a un gruppo specifico. Immagino sia una questione di gusti, ma sembra una modifica minore di sshd_config (che si traduce in un minor rischio di incasinare e bloccare tutti).

— un CVn il

@ MichaelKjörling Inoltre, AllowGroups significa che non è necessario disporre delle autorizzazioni di modifica per sshd_config se il team si espande o si restringe. Ciò potrebbe anche consentire a più tipi manageriali o stagisti di farlo.

— Nzall,

Aspetti positivi, nota che puoi combinare opzioni, avere AllowUsers itai root@192.168.0.*e AllowGroups ssh-userse non

— causerai