The secure file transfer subsystem can be defined in the ssh-server-config.xml file:

<services>
  <rule>
    <subsystem type="sftp" application="sft-server-g3" />
   ...
  </rule>
  ...
</services>

Using the SSH Tectia Server Configuration GUI on Windows, this can be set under the Services page, on the SFTP tab. See SFTP.

If you are sure you or your users do not need to create tunnels (possibly going around firewall restrictions or such), you can disable tunneling (port forwarding) altogether by adding the following to the ssh-server-config.xml file:

<services>
  <rule>
   <tunnel-local action="deny" />
   <tunnel-remote action="deny" />
   ...
  </rule>
  ...
</services>

Using the SSH Tectia Server Configuration GUI on Windows, these can be set under the Services page, on the Basic tab. See Basic.

If you need more fine-grained control, you can define user groups in the services block and apply the restrictions only to the specified groups.

Tunneling restrictions can be further defined with the src, dst, and listen elements. See Chapter 8 for more information.

If you only want to enable file transfers or tunneling for users in group remote-access, you can disable terminal access by adding the following to the ssh-server-config.xml file:

<services>
  <rule group="remote-access">
    <terminal action="deny" />
    ...
  </rule>
  ...
</services>

Using the SSH Tectia Server Configuration GUI on Windows, this can be set under the Services page, on the Basic tab. See Basic.

This setting denies also X11 and agent forwarding and shell commands for the specified group (unless some commands are explicitly allowed).

The users will be able to use SFTP and other subsystems defined in the SSH Tectia Server configuration. Any other "exec" and "shell" requests will be denied for the users. This includes forced commands with public keys described in Forced Commands and the legacy style password changing when performed as forced command.

If you wish to restrict what users can do with remote commands, we recommend that you set deny as the default action, and then allow only some specific remote commands, if any. This way you do not accidentally leave some unnoticed commands as allowed.

It is possible to deny the use of remote commands altogether or to specify which commands are denied.

When terminal access is denied, also the remote commands are denied unless you explicitly define the commands as allowed or as forced. With the terminal access denied, it is advisable to allow only some specific commands. If all commands are allowed, the remote command users can perform most of the things they could do with the terminal access allowed. For more information, see command.

Note that restrictions on remote commands apply also to OpenSSH-style SCP operations to the server.

You can disable remote commands totally by adding the following settings to the ssh-server-config.xml file:

<services>
  <rule>
   <command action="deny" />
   <terminal action="deny" />
   ...
  </rule>
  ...
</services>

If you need more fine-grained control, you can define user groups in the services block and apply the restrictions only to the specified groups.

Using the SSH Tectia Server Configuration GUI on Windows, remote commands can be disabled under the Services page, on the Basic tab. See Basic.

By default, file access by the user using the SFTP subsystem is restricted by the filesystem access controls. On Unix, access can be further restricted with the usage of the chroot attribute. The chroot attribute can be used with the subsystem, terminal, and command elements. See Chrooting (Unix).

The chroot attribute must be a directory path. Values %username%, %homedir%, and %hostname% will be substituted with the username, user's home directory, and the FQDN of the connected client, respectively.

An example of chroot usage is shown below:

<services>
  <rule>
    <subsystem type="sftp" 
               application="sft-server-g3" 
               action="allow" 
               chroot="/home/%username%" />
   ...
  </rule>
  ...
</services>

Here %username% will be replaced. For the user example, the path would be /home/example. During an SFTP session, the user is now restricted to this directory (and its subdirectories).

	Note
	Chrooting the SFTP subsystem affects both SFTP and SCP2 operations to the server, but it does NOT affect OpenSSH-style SCP operations. To chroot also OpenSSH SCP, you should chroot the scp1-compat-srv command. For instructions, see Chrooting Remote Commands. If you do not need to allow OpenSSH SCP, you can disable all remote commands as described in Disabling Remote Commands above.

Virtual folders can be used to restrict the folders the user is able to access via SFTP and SCP2.

By default, if no virtual folders are explicitly defined in the configuration file, the user can access all drives via SFTP and SCP2 operations, the user's SFTP session starts in the %USERPROFILE% directory, and that is the target directory for SCP2 operations.

When any virtual folders are defined, the user access is limited to the specified folders only. Note that the user's home directory must be under one of the defined virtual folders.

It is also possible to change the SFTP starting directory and the target directory of the SCP2 operations by defining the home attribute in the configuration file. Its value can also contain special strings which are expanded by SSH Tectia Server. These strings are %username% (user's login name), %username-without-domain% (user's login name without the domain part), %homedir% (user's home directory), and %hostname% (the name of the host the user is logging from, reverse mapped from the IP).

The following example sets the starting directory to a user-specific subdirectory under C:\SFTP.

<services>
  <rule>
    <subsystem type="sftp" application="sft-server-g3.exe" action="allow">
      <attribute name="home" value="C:\SFTP\%username-without-domain%" />
    </subsystem>
   ...
  </rule>
  ...
</services>

If the home attribute is included in the configuration file but it is given an empty value, or if a directory that is denied by the virtual folder settings is specified, the session will start in the virtual SFTP root directory.

<services>
  <rule>
    <subsystem type="sftp" application="sft-server-g3.exe" action="allow">
      <attribute name="home" value="" />
    </subsystem>
   ...
  </rule>
  ...
</services>

	Note
	The virtual SFTP root directory is not an actual directory on disk and no files can be written there.

To define custom virtual folders, the virtual-folder attribute can be used in the configuration file. If any virtual folders are defined, the default drive letters are not used. If you still want to use the drive letters, they need to be defined in the configuration file.

The value of virtual folder can contain the same special strings as the value of home (%username%, %username-without-domain%, %homedir%, and %hostname%).

The following example allows access to the C: drive and a user-specific subdirectory under the SFTP directory on the D: drive (when a user changes directory to D:, he is actually directed to the user-specific directory). The session starts in the virtual SFTP root directory. No other directory can be accessed via SFTP.

<services>
  <rule>
    <subsystem type="sftp" application="sft-server-g3.exe" action="allow">
      <attribute name="home" value="" />
      <attribute name="virtual-folder" value="C:=C:\" />
      <attribute name="virtual-folder" value="D:=D:\SFTP\%username%" />
    </subsystem>
   ...
  </rule>
  ...
</services>

In the SSH Tectia Server Configuration tool, virtual folders can be set under the Services page on the SFTP tab. See SFTP. The settings in the example above are shown in Figure 7.2.

Figure 7.2. Defining virtual folders