OpenSSH: Różnica między wewnętrznym serwerem sftp a serwerem sftp

Dlaczego istnieją dwa sposoby konfiguracji SFTP z OpenSSH i kiedy z których korzystać? Czy jest jakaś różnica między nimi?

Mam na myśli, że pierwszy używa lib z OpenSSH, a drugi mówi „użyj wewnętrznego”, więc jest to również OpenSSH?

Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

Zarówno sftp-serveri internal-sftpsą częścią OpenSSH. sftp-serverjest samodzielnym plikiem binarnym. internal-sftpjest tylko słowem kluczowym konfiguracji, które mówi, sshdaby użyć wbudowanego kodu serwera SFTP sshd, zamiast uruchamiania innego procesu (zazwyczaj sftp-server).

Z funkcjonalnego punktu widzenia, sftp-serveri internal-sftpsą prawie identyczne. Są zbudowane z tego samego kodu źródłowego.

Główną zaletą internal-sftpjest to, że nie wymaga plików pomocniczych, gdy jest używany z ChrootDirectorydyrektywą .

Cytaty ze strony sshd_config(5)man :

• Do Subsystemdyrektywy :

  Komenda sftp-serverimplementuje podsystem transferu plików SFTP.

  Alternatywnie nazwa internal-sftpimplementuje wewnętrzny serwer SFTP. Może to uprościć konfigurację, ChrootDirectoryaby wymusić inny system plików root na klientach.

• Do ForceCommanddyrektywy :

  Podanie polecenia internal-sftpwymusi użycie procesowego serwera SFTP, który nie wymaga plików pomocniczych, jeśli jest używany z ChrootDirectory.

• Do ChrootDirectorydyrektywy :

  ChrootDirectoryMusi zawierać niezbędne pliki i katalogi do obsługi sesji użytkownika. Interaktywnej sesji wymaga to co najmniej powłokę, zwykle shoraz podstawowych /devwęzłów, takich jak null, zero, stdin, stdout, stderr, i ttyurządzenia. W przypadku sesji przesyłania plików za pomocą SFTP nie jest wymagana dodatkowa konfiguracja środowiska, jeśli używany jest serwer sftp w trakcie procesu, chociaż sesje, które używają rejestrowania, mogą wymagać /dev/logw katalogu chroot w niektórych systemach operacyjnych ( sftp-serverszczegółowe informacje).

Kolejną zaletą internal-sftpjest wydajność, ponieważ nie jest konieczne uruchamianie dla niej nowego podprocesu.

internal-sftpDodano znacznie później (OpenSSH 4.9p1 w 2008 roku?) Niż samodzielny sftp-serverbinarnego, ale to jest domyślnym teraz.

Uważam, że nie ma powodu, aby używać go sftp-serverdo nowych instalacji.

Może się wydawać, że sshdmoże automatycznie korzystać internal-sftp, gdy się pojawi sftp-server, ponieważ funkcjonalność jest identyczna i internal-sftpma nawet powyższe zalety. Ale są przypadki skrajne, w których występują różnice.

Kilka przykładów:

• Administrator może polegać na konfiguracji powłoki logowania, aby uniemożliwić zalogowanie się niektórym użytkownikom. Przełączenie na internal-sftpto pomija ograniczenie, ponieważ powłoka logowania nie jest już zaangażowana.

• Korzystając z sftp-serverbinarnego (będącego samodzielnym procesem), możesz użyć kilku hacków, takich jak uruchomienie SFTP podsudo .

• W przypadku SSH-1 (jeśli ktoś nadal go używa), Subsystemdyrektywa w ogóle nie jest zaangażowana. Klient SFTP korzystający z SSH-1 wyraźnie informuje serwer, jaki plik binarny powinien uruchomić serwer. Tak więc starsze klienty SSH-1 SFTP mają sftp-servermocno zakodowane nazwy.

Istnieją alternatywne implementacje SFTP, których można używać razem z OpenSSH:

• http://www.greenend.org.uk/rjk/sftpserver/
• https://github.com/mysecureshell/mysecureshell

Możesz zablokować klucz autoryzowany na zewnętrznym serwerze sftp.

polecenie = "/ usr / libexec / openssh / sftp-server" ssh-rsa AAAA… == użytkownik@host.com

Gdy to zrobisz, użytkownik może sftp, ale nie może scp ani ssh:

$ sftp host: / etc / group / tmp
Łączenie z hostem ...
Pobieranie / etc / group do / tmp / group
/ etc / group 100% 870 0,9 KB / s 00:00

Próba zrobienia czegokolwiek innego po prostu się zawiesi:

$ scp host: / etc / group / tmp
Zabity sygnałem 2.

$ ssh uptime hosta
Zabity sygnałem 2.

Niestety, nie ma łatwego sposobu na zablokowanie klucza w chroot, chyba że sshd_config zostanie zmodyfikowany. Byłoby naprawdę fajnie, gdyby użytkownik mógł obejść się bez interwencji administratora systemu.