Czy można przyznać użytkownikom dostęp sftp bez dostępu do powłoki? Jeśli tak, w jaki sposób jest to realizowane?


29

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


scponly github.com/scponly/scponly/wiki chroot opcjonalnie
user2497

Odpowiedzi:


11

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.


Ok wykonałem wszystkie kroki, ale się nie zalogowałem
Sollosa

2
@Sollosa Spróbuj Match User [SFTP user] ForceCommand internal-sftptylko, bez chrootowania.
Martin Prikryl

@MartinPrikryl to działało Martin, dzięki, właśnie usunąłem parametr chrootdirectory i altówkę
Sollosa

1
chroot
Ponadto

37

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.


2
To powinna być zaakceptowana odpowiedź. Zapewnia rozwiązanie, a także przedstawia wyjaśnienie każdego kroku.
kemotep

1
To naprawdę świetna odpowiedź z świetnymi dodatkowymi poradami bezpieczeństwa, ale martwię się o tych użytkowników, których systemy polegają na logowaniu się hasłem, logowaniu do roota itp. Oczywiście, że to nie jest dobre, ale może przenieść zmiany związane z ogólną poprawą bezpieczeństwa do ich własną sekcję, aby dostępna była odpowiedź na pytanie z minimalnymi zmianami?
Josh Rumbut

1
@JoshRumbut Nie chciałem przepisywać odpowiedzi na twoje (bardzo poprawne) uwagi, częściowo dlatego, że tak naprawdę pokazuje My Way ™, a częściowo ma nadzieję, że może to być coś w rodzaju kanonicznej, domyślnie bezpiecznej konfiguracji SSH przykład, że wiele osób uważa za przydatne. Jako kompromis starałem się, aby było o wiele jaśniej, że logowanie do roota i uwierzytelnianie hasła nie będą działać, i
załączyłem

1
Dobra odpowiedź, imo największe wady innych odpowiedzi nie uwzględniały aspektów bezpieczeństwa, głównie chroot. +1
Rui F Ribeiro

1
Chroot nie będzie działał przez ogólny% h. Zaskakujące, że musisz chown root:rootichmod og-w
kubańczyk

1

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

# usermod -s /sbin/nologin username

Próbowałem, ale użytkownik nie może zalogować się przez sftp, nie wiem dlaczego. Używam centos btw.
Sollosa

@Sollosa Prawdopodobnie problem z uprawnieniami w chroot sftp lub sshd_config ma problem. Powinieneś zaktualizować swoje pytanie, aby zawierało uprawnienia do katalogu chroot i twojego sshd_config z wszelkimi poufnymi informacjami zredagowanymi.
Kefka

Wierzę (choć nie mogę tego teraz przetestować), że pozwala to SFTP tylko wtedy, gdy jest Subsystem sftp internal-sftp) (a może ForceCommand internal-sftp). Jeśli są wspólne Subsystem sftp /path/to/sftp-server, nologinzapobiegną nawet SFTP.
Martin Prikryl

@MartinPrikryl Źle zrozumiałem ich oryginalne, niezredagowane pytanie, pytając, jak wyłączyć dostęp do powłoki dla użytkowników na skądinąd funkcjonalnym serwerze sftp. Nie spałam w tym czasie przez około dziesięć minut, więc nie byłam tak pewna siebie, jak mogłam się spodziewać. Chociaż nie wiedziałem, że serwer sftp wymaga od użytkownika posiadania poprawnej powłoki do działania - wydaje się to potencjalnie niebezpieczne. Zawsze używam wewnętrznego sftp tylko z przyzwyczajenia, ponieważ zawsze tak to robiłem.
Kefka

Zobacz moją odpowiedź na OpenSSH: Różnica między wewnętrznym serwerem sftp a serwerem sftp (szczególnie sekcja na końcu)
Martin Prikryl

0

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


2
Myślę, że OP chciał, aby użytkownicy (którzy prawdopodobnie mają nazwy użytkowników i hasła) nie mogli używać zwykłego klienta SSH do łączenia się z serwerem i wykonywania dowolnych poleceń, ale ci sami użytkownicy mogliby przesyłać pliki przez SFTP.
John_ReinstateMonica
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.