Jak zezwolić ssh na rootowanie użytkownika tylko z sieci lokalnej?

Zainstalowałem Google-Authenticator na maszynie CentOS 6.5 i skonfigurowałem niektórych użytkowników do obsługi OTP.

Podczas edycji /etc/ssh/sshd_configwidziałem dyrektywę „ PermitRootLogin”, która jest domyślnie komentowana.

Chciałbym ustawić „ PermitRootLogin no”, ale nadal będę mógł ssh do komputera jako root tylko z sieci lokalnej.

Czy to jest możliwe?

linux ssh centos6

— Itai Ganot
źródło

Nigdy tego nie rób. SSH w jako twoi użytkownicy, a następnie użyj sudo, aby podnieść uprawnienia. Zrób to, aby pozostawił ślad papieru, abyś wiedział, które konto zostało naruszone.

— SnakeDoc,

@SnakeDoc: To jedna szkoła myślenia, ale nie jest to jednoznaczne i powiedziałbym, że jest odwrotnie. sudo to ogromna, złożona powierzchnia ataku, a nie coś, co chciałbym kiedykolwiek zainstalować. SSH pubkey auth to znacznie mniejsza powierzchnia ataku. Można rejestrować oba, ale rejestrowanie nie jest bardzo przydatne, gdy użytkownik (root) może edytować lub usuwać dzienniki, co zawsze ma miejsce, chyba że zalogujesz się do zewnętrznego magazynu tylko z dołączaniem.

— R ..

@R .. Jeśli poprawnie skonfigurujesz sudoers, stosując zasadę najmniejszych uprawnień, opisane przez ciebie problemy w dużej mierze nie stanowią problemu. Żaden użytkownik nie powinien mieć możliwości ssh i sudo - surootowania, ani robienia czegokolwiek, czego jego użytkownicy nie potrzebują (w sudoerach używasz białej listy do poleceń). Jeśli potrzebujesz roota, musisz fizycznie być przy konsoli - tj. Rootowanie nad SSH nigdy nie powinno być dozwolone ... klucze czy nie.

— SnakeDoc,

@SnakeDoc: Mylisz się. Sudo ma zarówno swoje własne złożone powierzchnie ataku, jak i fundamentalną złożoną powierzchnię ataku, która jest nieodłączna od bycia suid binarnym, w postaci całego stanu odziedziczonego po całym execve. W niektórych przypadkach błąd w samym programie suid (suid) nie jest nawet potrzebny; błędy w podstawowej infrastrukturze, takiej jak dynamiczny linker (np. CVE-2010-3856) mogą być wystarczające.

— R ..

@R .. Zakładasz, że zawsze będziesz wiedział, jeśli nastąpi wyciek klucza. To tylko przypuszczenie. Co więcej, twój atakujący ma uprawnienia roota. Nadal lepiej jest wysłać je za pośrednictwem nieuprzywilejowanego konta i zmusić do podniesienia uprawnień do rootowania. W ten sposób masz klucz, który należy wyciec, hasło do złamania, a następnie hasło zwykłego konta użytkownika do złamania. A jeśli atakujący przejdzie przez to wszystko ... nie może nic zrobić, ponieważ ten użytkownik jest skonfigurowany pod sudoers z bardzo ograniczonymi możliwościami ... Widzisz teraz korzyść? Nie zezwalaj na bezpośrednie logowanie do roota przez okres ssh ... To dobra higiena

— SnakeDoc,

Odpowiedzi:

Użyj Matchparametru config w /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

Widzieć man sshd_config

— Sven
źródło

Dlaczego o tym nie pomyślałem? Dzięki kolego

— Itai Ganot

Możesz także ograniczyć źródło kluczy uwierzytelniania w ~root/.ssh/authorized_keys. Przedrostek klucza za pomocą from="192.168.0.0/24 ".

— BillThor,

Zmieniłbym to, aby zezwolić także na adresy lokalne IPv6. Sposób działania adresów lokalnych dla łącza w IPv6 czyni je bardzo odpornymi na źle skonfigurowane sieci. Co oznacza, że jeśli potrzebujesz ssh, aby naprawić błędną konfigurację sieci, możliwe jest, że użycie adresu lokalnego łącza IPv6 jest jedyną opcją.

— kasperd 17.07.16

Do Twojej wiadomości Jeśli dodatkowo korzystasz z dyrektywy AllowUser , musisz dodatkowo (i wbrew intuicji) zrobićAllowUser root

— Robert Riedl

Match addressMetoda została już wspomniano, ale można także ograniczyć użytkowników (lub grupy), które są dozwolone, aby zalogować się na systemie. Na przykład, aby ograniczyć logowanie do użytkownika itai(z dowolnego miejsca) i root(z określonej sieci), użyj:

AllowUsers itai root@192.168.0.*

Zapobiega to apachelogowaniu się przez wszystkich innych użytkowników (np. ) Za pośrednictwem protokołu SSH.

Zobacz także AllowUserssłowo kluczowe w podręczniku sshd_config (5) .

— Lekensteyn
źródło

Wolę AllowGroupsi dodaję wszystkich użytkowników, którzy powinni mieć możliwość zalogowania się przy użyciu SSH do określonej grupy. Zgadnij, to kwestia gustu, ale wydaje się, że to mniej edycji sshd_config (co przekłada się na mniejsze ryzyko zepsucia i zablokowania wszystkich).

— CVn

@ MichaelKjörling Ponadto AllowGroups oznacza, że nie potrzebujesz uprawnień do edycji sshd_config, jeśli Twój zespół się powiększy lub zmniejszy. Może to nawet pozwolić na to, aby zrobić to więcej menedżerów lub stażystów.

— Nzall,

Dobre punkty, pamiętaj, że możesz łączyć opcje, mieć AllowUsers itai root@192.168.0.*i AllowGroups ssh-usersnie spowoduje to przypadkowej blokady w przypadku, gdy stażysta przypadkowo wyczyści grupę :)

— Lekensteyn