Zarówno sftp-server
i internal-sftp
są częścią OpenSSH. sftp-server
jest samodzielnym plikiem binarnym. internal-sftp
jest tylko słowem kluczowym konfiguracji, które mówi, sshd
aby użyć wbudowanego kodu serwera SFTP sshd
, zamiast uruchamiania innego procesu (zazwyczaj sftp-server
).
Z funkcjonalnego punktu widzenia, sftp-server
i internal-sftp
są prawie identyczne. Są zbudowane z tego samego kodu źródłowego.
Główną zaletą internal-sftp
jest to, że nie wymaga plików pomocniczych, gdy jest używany z ChrootDirectory
dyrektywą .
Cytaty ze strony sshd_config(5)
man :
Kolejną zaletą internal-sftp
jest wydajność, ponieważ nie jest konieczne uruchamianie dla niej nowego podprocesu.
internal-sftp
Dodano znacznie później (OpenSSH 4.9p1 w 2008 roku?) Niż samodzielny sftp-server
binarnego, ale to jest domyślnym teraz.
Uważam, że nie ma powodu, aby używać go sftp-server
do nowych instalacji.
Może się wydawać, że sshd
może automatycznie korzystać internal-sftp
, gdy się pojawi sftp-server
, ponieważ funkcjonalność jest identyczna i internal-sftp
ma 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-sftp
to pomija ograniczenie, ponieważ powłoka logowania nie jest już zaangażowana.
Korzystając z sftp-server
binarnego (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), Subsystem
dyrektywa 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-server
mocno zakodowane nazwy.
ForceCommand internal-sftp
powinien osiągnąć to samosshfs host:/home/user/.ssh ~/hackme
edytować wszystkie ustawienia z powrotem, aby otworzyć dostęp, jeśli później zmienisz zdanie.