OpenSSH coś w stylu „wewnętrznego sftp”, ale dla SCP?

16

Korzystam ze stabilnej wersji Debiana i chcę ustanowić następujące środowisko dla użytkowników w mojej grupie „sftponly”:

  • osadzony w więzieniu
  • można przesyłać za pomocą SFTP
  • może przesyłać z SCP
  • nie można zalogować się interaktywnie za pomocą SSH

Z moich eksperymentów i badań wynika, że ​​następująca zwrotka w sshd_config prowadzi mnie tam w 90%:

Match group sftponly
ChrootDirectory /sftp/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

To daje mi więziony SFTP i brak SSH, co jest dobre. Ale wyłącza również SCP, co jest mniej niż idealne, ponieważ sporo klientów to starsze, skrypty, które używają SCP zamiast SFTP (serwer, który zastępujemy, obsługuje oba protokoły), a ponieważ ci klienci nie są pod naszą kontrolą i łatwo zmodyfikowane, prawdopodobnie nie jest możliwe całkowite wyłączenie SCP.

Ma to sens, że ta konfiguracja wyłączyłaby SCP, ponieważ przychodzące połączenia SCP powodują, że sshd odradza proces `scp 'za pośrednictwem powłoki logowania użytkownika, tak jak ten użytkownik. Wydaje się, że to samo zwykle dotyczy SFTP, gdyby nie specjalny moduł obsługi „wewnętrznego sftp”.

Przypuszczam, że moje pytanie brzmi: czy istnieje sposób na uzyskanie takiego samego efektu jak „wewnętrzny-sftp”, ale w przypadku SCP, bez uciekania się do korzystania z narzędzi innych firm, takich jak scponly i rssh? Naprawdę fajną rzeczą w „Internal-sftp” jest to, że nie wymaga konfigurowania więzienia z plikami pomocniczymi lub radzenia sobie z potencjalnie możliwymi do wykorzystania plikami binarnymi setuid stron trzecich (w szczególności rssh ma historię exploitów).

brianjcohen
źródło
1
Czy klienci łączą się przy użyciu pliku klucza ssh, czy też używają haseł? Jeśli jest to plik klucza, można ograniczyć to, co mogą zrobić.
Jenny D.
Łączą się za pomocą haseł.
brianjcohen

Odpowiedzi:

3

Spójrz na rssh, który jest alternatywną powłoką, która pozwala na ograniczony dostęp do systemu.

rssh jest ograniczoną powłoką zapewniającą ograniczony dostęp do hosta przez ssh (1), pozwalając użytkownikowi, którego powłoka jest skonfigurowana na rssh, używać jednego lub więcej poleceń scp (1), sftp (1) cvs (1) ), rdist (1) i rsync (1) i tylko te polecenia.

Za pomocą pliku rssh.conf można skonfigurować, które polecenia mogą być używane dla poszczególnych użytkowników lub całego systemu

Alternatywnie możesz użyć scponly do robienia tego, co chcesz. Działa jak opakowanie pakietu ssh i umożliwia przesyłanie plików, ale nie dostęp do powłoki.

użytkownik9517
źródło
2

Czy musisz to zrobić przez ssh?

JEŚLI możesz spróbować ustawić ich powłokę na:

/usr/libexec/openssh/sftp-server

I upewnij się, że dodałeś powyższe do / etc / shells

Jeśli chcesz zrezygnować z korzystania z wbudowanych kont, możesz skonfigurować proftpd

Konfiguruję bezpieczny SFTP za pomocą proftpd. skompilowane proftpd tak:

./configure --prefix = / usr --sysconfdir = / etc --with-modules = mod_sftp

Można skorzystać z tego artykułu poniżej i kilku innych informacji na temat jego konfiguracji w Google:

http://tutorialgenius.blogspot.com/2012/02/linux-installing-and-configuring.html

coderwhiz
źródło
2

Obawiam się, że nie ma nic równie łatwego lub niezawodnego z OpenSSH, ponieważ, jak zauważyłeś, jest wbudowany serwer SFTP, ale nie ma wbudowanego serwera SCP.

Ostrzeżenie: sugestia Vince'a Berka jest zła z wielu powodów:

  1. Na zachowanie powłoki w odniesieniu do plików startowych mogą mieć wpływ zmienne środowiskowe, które SSH może ustawiać zdalnie w zależności od konfiguracji serwera.
  2. Użytkownik może po prostu uruchomić ssh / bin / bash i uzyskać powłokę. Nie będzie miał tty, więc korzystanie z niego będzie niewygodne, ale co z tego ... nie wspominając o wszystkich innych programach, które może uruchamiać, których prawdopodobnie nie chcesz.
  3. Zmiana uprawnień pliku .bash_profile nie przynosi wiele korzyści, jeśli użytkownik może po prostu wykonać polecenie „ssh host rm -f .bash_profile”; nic nie wspomniano o uprawnieniach do katalogu domowego.

... i tak dalej. Takie podejście jest po prostu zbyt kruche.

Richard E. Silverman
źródło
0

To narzędzie innej firmy, które nie wchodzi w zakres pytania, ale pomyślałem, że i tak zasługuje na wzmiankę.

Jailkit: https://olivier.sessink.nl/jailkit/

Posiada kolekcję narzędzi ułatwiających konfigurowanie więzów użytkownika - kopiowanie plików binarnych i bibliotek do więzienia oraz konfigurowanie rejestrowania z wnętrza więzienia do systemu operacyjnego. Użyłem go do budowania chroots tylko dla sftp / scp / rsync.

Jest również wyposażony w jk_lsh(jailkit limited shell), którego można używać poza więzieniem, aby ograniczyć polecenia, które użytkownik może uruchamiać, jeśli np. Chcesz zezwolić na scp / sftp / rsync tylko bez chroota.

chutz
źródło
-1

Oto sztuczka, jak wykonać tę stronę serwera. Ustaw powłokę użytkowników, powiedzmy, bash:

usermod -S /bin/bash [username]

Teraz utwórz w swoim katalogu głównym plik „.bash_profile” z następującym wierszem:

[ -n "$PS1" ] && exit

Powoduje to, że sesje nieinteraktywne (takie jak „scp”) są kontynuowane. Jeśli jednak spróbują się zalogować „ssh”, wywoływane jest „wyjście”, a połączenie zostaje zamknięte.

Upewnij się, że nie mogą „sftp” nowego „.bash_profile” w swoich katalogach domowych!

chown root:root .bash_profile

Mam nadzieję, że to pomaga!

Vince Berk
źródło
Podejście to nie wydaje się uwzględniać wymogu więzienia.
brianjcohen
Tak, niestety musiałbyś stworzyć ręczne środowisko chroot dla strony 'scp', pokrywające się z katalogiem chroot podanym w sshd_config i wykonać powyższą sztuczkę dla każdego użytkownika, którego chcesz ograniczyć. „Scp” nie działa z wewnętrznym serwerem sftp.
Vince Berk,