Ssh – the difference between SSH and SSH Tunneling

Problem solved:

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

...apparently, 'localhost' was not liked by the remote host. Yet, remote /etc/hosts contains:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

while the local network interface is

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33184
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

Sigh. so much for the bounty of 100rp I put on :)

Both sftp-server and internal-sftp are part of OpenSSH. The sftp-server is a standalone binary. The internal-sftp is just a configuration keyword that tells sshd to use the SFTP server code built-into the sshd, instead of running another process (what would typically be the sftp-server).

The internal-sftp was added much later (OpenSSH 4.9p1 in 2008?) than the standalone sftp-server binary. But it is the default by now. The sftp-server is now redundant and is kept probably for a backward compatibility.

I believe there's no reason to use the sftp-server for new installations.

From a functional point of view, the sftp-server and internal-sftp are almost identical. They are built from the same source code.

The main advantage of the internal-sftp is, that it requires no support files when used with ChrootDirectory directive.

Quotes from the sshd_config(5) man page:

• For Subsystem directive:

  The command sftp-server implements the SFTP file transfer subsystem.

  Alternately the name internal-sftp implements an in-process SFTP server. This may simplify configurations using ChrootDirectory to force a different filesystem root on clients.

• For ForceCommand directive:

  Specifying a command of internal-sftp will force the use of an in-process SFTP server that requires no support files when used with ChrootDirectory.

• For ChrootDirectory directive:

  The ChrootDirectory must contain the necessary files and directories to support the user's session. For an interactive session this requires at least a shell, typically sh, and basic /dev nodes such as null, zero, stdin, stdout, stderr, and tty devices. For file transfer sessions using SFTP no additional configuration of the environment is necessary if the in-process sftp-server is used, though sessions which use logging may require /dev/log inside the chroot directory on some operating systems (see sftp-server for details).

Another advantage of the internal-sftp is a performance, as it's not necessary to run a new sub-process for it.

It may seem that the sshd could automatically use the internal-sftp, when it encounters the sftp-server, as the functionality is identical and the internal-sftp has even the above advantages. But there are edge cases, where there are differences.

Few examples:

• Administrator may rely on a login shell configuration to prevent certain users from logging in. Switching to the internal-sftp would bypass the restriction, as the login shell is no longer involved.

• Using the sftp-server binary (being a standalone process) you can use some hacks, like running the SFTP under sudo.

• For SSH-1 (if anyone is still using it), Subsystem directive is not involved at all. An SFTP client using SSH-1 tells the server explicitly, what binary the server should run. So legacy SSH-1 SFTP clients have the sftp-server name hard-coded.