OpenSSH: Différence entre internal-sftp et sftp-server

Pourquoi existe-t-il deux manières de configurer SFTP avec OpenSSH et quand utiliser lesquelles? Y a-t-il une différence entre eux?

Je veux dire que le premier utilise une lib de OpenSSH et le second dit "use the internal", donc c'est aussi OpenSSH?

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

Les deux sftp-serveret internal-sftpfont partie d'OpenSSH. sftp-serverest un binaire autonome. internal-sftpest juste un mot-clé de configuration qui indique sshdd’utiliser le code de serveur SFTP intégré au sshdlieu d’exécuter un autre processus (généralement le sftp-server).

Du point de vue fonctionnel, sftp-serveret internal-sftpsont presque identiques. Ils sont construits à partir du même code source.

Le principal avantage internal-sftpest qu'il ne nécessite aucun fichier de support lorsqu'il est utilisé avec ChrootDirectorydirective .

Citations de la sshd_config(5)page de manuel :

• Pour Subsystemdirective :

  La commande sftp-serverimplémente le sous-système de transfert de fichiers SFTP.

  Sinon, le nom internal-sftpimplémente un serveur SFTP en cours de traitement. Cela peut simplifier les configurations en utilisant ChrootDirectorypour forcer une autre racine de système de fichiers sur les clients.

• Pour ForceCommanddirective :

  Le fait de spécifier une commande de internal-sftpforcera l'utilisation d'un serveur SFTP en cours de processus qui ne nécessite aucun fichier de support lorsqu'il est utilisé avec ChrootDirectory.

• Pour ChrootDirectorydirective :

  Le ChrootDirectorydoit contenir les fichiers et répertoires nécessaires pour prendre en charge la session de l'utilisateur. Pour une session interactive cela nécessite au moins une coquille, généralement sh, et de base /devnœuds tels que null, zero, stdin, stdout, stderret ttydispositifs. Pour les sessions de transfert de fichiers utilisant SFTP, aucune configuration supplémentaire de l'environnement n'est nécessaire si le serveur sftp en cours de traitement est utilisé, bien que les sessions utilisant la consignation puissent nécessiter /dev/logun emplacement dans le répertoire chroot de certains systèmes d'exploitation (voir sftp-serverpour plus de détails).

Un autre avantage de internal-sftpla performance est qu'il n'est pas nécessaire d'exécuter un nouveau sous-processus.

Le a internal-sftpété ajouté bien plus tard (OpenSSH 4.9p1 en 2008?) Que le sftp-serverbinaire autonome , mais c'est la valeur par défaut pour le moment.

Je crois qu'il n'y a aucune raison d'utiliser le sftp-serverpour de nouvelles installations.

Il peut sembler que vous sshdpourriez utiliser automatiquement internal-sftp, quand il rencontre sftp-server, comme la fonctionnalité est identique et internal-sftpa même les avantages ci-dessus. Mais il y a des cas extrêmes, où il y a des différences.

Quelques exemples:

• L'administrateur peut s'appuyer sur une configuration de shell de connexion pour empêcher certains utilisateurs de se connecter. Le passage à la valeur internal-sftpcontournerait la restriction, car le shell de connexion n'est plus impliqué.

• En utilisant sftp-serverbinaire (étant un processus autonome), vous pouvez utiliser certains hacks, comme exécuter le SFTP soussudo .

• Pour SSH-1 (si quelqu'un l'utilise encore), la Subsystemdirective n'est pas impliquée du tout. Un client SFTP utilisant SSH-1 indique explicitement au serveur le fichier binaire que le serveur doit exécuter. Ainsi, les clients SSH-1 SFTP hérités ont un sftp-servernom codé en dur.

Il existe d'autres implémentations SFTP pouvant être utilisées avec OpenSSH:

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

Vous pouvez verrouiller une authorised_key sur le serveur sftp externe.

command = "/ usr / libexec / openssh / sftp-server" ssh-rsa AAAA… == user@host.com

Lorsque vous le faites, votre utilisateur peut sftp, mais ne peut pas scp ou ssh:

$ hôte sftp: / etc / group / tmp
Connexion à l'hôte ...
Récupérer / etc / group dans / tmp / group
/ etc / group 100% 870 0,9 Ko / s 00:00

Tenter de faire autre chose ne tient qu'à:

$ scp host: / etc / group / tmp
Tué par le signal 2.

Temps de disponibilité de l'hôte $ ssh
Tué par le signal 2.

Hélas, il n'y a pas de moyen facile pour une clé d'être verrouillée sur un chroot à moins que sshd_config ne soit modifié. Ce serait vraiment bien pour un utilisateur de pouvoir se passer de l’intervention du gestionnaire du système.