Mam szereg użytkowników, którzy muszą po prostu przesyłać pliki do swoich homedirów. Myślę, że wystarczy sftp, ale nie chcę, aby logowali się przez powłokę. Czy to możliwe? Moja platforma to centos 7, katalogi użytkowników są przechowywane, powiedzmy / personal / $ user

Stworzyłem użytkownika z tymi ustawieniami

useradd -m -d /personal/user1 -s /sbin/nologin

przypisałem użytkownikowi hasło, a kiedy używam sftp do zalogowania się na maszynie, mówi, że nie można się połączyć.

Edytuj swój, /etc/ssh/sshd_configaby zawierał:

Match User [SFTP user]
ForceCommand internal-sftp

Restart sshd. Jeśli masz wielu użytkowników, umieść je wszystkie w wierszu dopasowania, oddzielając je przecinkami:

Match User User1,User2,User3

Kluczem do skonfigurowania, sftpaby nie zezwalać na dostęp do powłoki, jest ograniczenie użytkowników za pomocą ForceCommand opcji.

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

1. 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.

2. 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ą.

3. 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.)

4. 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.

5. 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.

wystarczy zmienić ich domyślną powłokę na / sbin / nologin. Zakładając, że większość odmian systemu Linux:

# usermod -s /sbin/nologin username

możesz użyć tftp. cokolwiek powyżej ssh będzie wymagać uwierzytelnienia (key | pass).

chociaż tftp można zabezpieczyć, warto ponownie rozważyć decyzję o zapewnieniu dostępu do czegokolwiek bez uwierzytelnienia.

http://manpages.ubuntu.com/manpages/bionic/man1/tftp.1.html