Podoba mi się następująca konfiguracja do zarządzania dostępem SSH, której używam w pracy do zarządzania grupą użytkowników na małej flocie serwerów. Bezpieczeństwo i łatwość zarządzania są wysoko na liście moich priorytetów.
Jego kluczowymi funkcjami są łatwe zarządzanie prawami SSH poprzez członkostwo w grupie Unix, posiadanie ściśle określonych uprawnień i domyślna ochrona.
Konfiguracja
Zainstaluj oprogramowanie (opcjonalne, ale przydatne):
yum install members # or apt install members
Dodaj grupy:
addgroup --system allowssh
addgroup --system sftponly
W /etc/ssh/sshd_configupewnij się, że następujące ustawienia No:
PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no
Na koniec /etc/ssh/sshd_configdodaj te dwie zwrotki:
Match Group allowssh
PubkeyAuthentication yes
Match Group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
(nie zapomnij zrestartować SSH po edycji pliku)
Wyjaśnienie
Co to wszystko robi?
- Zawsze wyłącza logowanie do konta root, jako dodatkowy środek bezpieczeństwa.
- Zawsze wyłącza logowanie oparte na hasłach (słabe hasła stanowią duże ryzyko dla serwerów z uruchomionym sshd).
- Pozwala tylko na logowanie (pubkey) dla użytkowników w
allowsshgrupie.
- Użytkownicy w
sftponlygrupie nie mogą uzyskać powłoki przez SSH, tylko SFTP.
Zarządzanie dostępem jest następnie wykonywane po prostu przez zarządzanie członkostwem w grupie (zmiany wchodzą w życie natychmiast, nie jest wymagane ponowne uruchomienie SSH):
# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#
Zauważ, że twoi użytkownicy sftp muszą być członkami zarówno sftponly(aby upewnić się, że nie otrzymają powłoki), jak i allowssh(aby umożliwić logowanie w pierwszej kolejności).
Dalsza informacja
Pamiętaj, że ta konfiguracja nie pozwala na logowanie się za pomocą hasła ; wszystkie konta muszą korzystać z uwierzytelniania za pomocą klucza publicznego. Jest to prawdopodobnie największa wygrana w dziedzinie bezpieczeństwa, jaką można uzyskać dzięki SSH, więc uważam, że warto podjąć wysiłek, nawet jeśli musisz zacząć już teraz.
Jeśli naprawdę tego nie chcesz, dodaj także PasswordAuthentication yesdo Match Group allowsshzwrotki. Umożliwi to użytkownikom zarówno uwierzytelnianie klucza publicznego, jak i hasła allowssh.
Ta konfiguracja ogranicza dowolnego sftponlyużytkownika do katalogu domowego. Jeśli tego nie chcesz, usuń ChrootDirectory %hdyrektywę.
Jeśli chcesz , aby chrooting działał, ważne jest, aby katalog domowy użytkownika (i jakikolwiek katalog powyżej) był własnością root:rooti nie był zapisywany przez grupę / inne. Można podkatalogi katalogu domowego być własnością użytkownika i / lub zapisywać.
Tak, katalog domowy użytkownika musi należeć do użytkownika root i nie może być dla niego dyskredytowany. Niestety istnieją dobre powody tego ograniczenia. W zależności od sytuacji ChrootDirectory /homemoże być dobrą alternatywą.
Ustawienie powłoki sftponlyużytkowników na /sbin/nologinnie jest konieczne ani szkodliwe dla tego rozwiązania, ponieważ SSH ForceCommand internal-sftpzastępuje powłokę użytkownika.
Używanie /sbin/nologinmoże być pomocne w powstrzymywaniu ich od logowania się na inne sposoby (konsola fizyczna, samba itp.)
Ta konfiguracja nie pozwala na bezpośrednie rootlogowanie przez SSH; stanowi to dodatkową warstwę bezpieczeństwa. Jeśli naprawdę nie potrzebują bezpośredniego logowania roota, należy zmienić PermitRootLogindyrektywę. Rozważ ustawienie na forced-commands-only, prohibit-passwordi (w ostateczności) yes.
Aby uzyskać punkty bonusowe, sprawdź, kto może surootować; dodać grupę systemową o nazwie wheeli dodać / włączyć auth required pam_wheel.sow /etc/pam.d/su.