For the example use case, we need to override some of the Tectia Server default settings. This is done by creating an xml-format configuration file ssh-server-config.xml.

Create the configuration file by copying and renaming one of the following files (use the settings as a model):

/etc/ssh2/ssh-server-config-example.xml
/etc/ssh2/ssh-server-config-tutorial.xml

You can view the default settings in file:

/etc/ssh2/ssh-server-config-default.xml

The following example shows the configuration file with the settings required to produce the use case described in Configuring Tectia Server for Automated Secure File Transfer.

For instructions, see the sections below the configuration file example.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE secsh-server SYSTEM
   "/opt/tectia/share/auxdata/ssh-server-ng/ssh-server-ng-config-1.dtd" [
  <!ENTITY configdir PUBLIC "secsh:directory(config-server)" "">
]>
<secsh-server>

<!--This block defines the allowed cryptographic methods-->
<!--Keep the default settings--> 
 <params>
  <crypto-lib mode="standard" />
  <hostkey>
   <private file="&configdir;/hostkey" />
   <public file="&configdir;/hostkey.pub" />
  </hostkey>
  <listener id="listener" port="22" />
  <limits max-connections="256" max-processes="40" />
  </params>
 
<!--This block defines the allowed server authentication methods--> 
<!--Keep the default settings-->
 <connections>
  <connection action="allow">
   <cipher name="aes128-cbc" />
   <cipher name="aes192-cbc" />
   <cipher name="aes256-cbc" />
   <cipher name="aes128-ctr" />
   <cipher name="aes192-ctr" />
   <cipher name="aes256-ctr" />
   <cipher name="3des-cbc" />
   <cipher name="crypticore128@ssh.com" />
   <mac name="hmac-sha1" />
   <mac name="hmac-sha1-96" />
   <mac name="hmac-sha256-2@ssh.com" />
   <mac name="hmac-sha224@ssh.com" />
   <mac name="hmac-sha256@ssh.com" />
   <mac name="hmac-sha384@ssh.com" />
   <mac name="hmac-sha512@ssh.com" />
   <mac name="crypticore-mac@ssh.com" />
  </connection>
 </connections>

<!--This block defines the allowed user authentication methods--> 
<!--Allow only public key authentication--> 
 <authentication-methods login-grace-time="600">
  <authentication action="allow">
   <auth-publickey />
  </authentication>
 </authentication-methods>
 
<!--This block defines first user groups and then a set of rules for each group--> 
<!--The default settings are applied to users left outside the groups--> 
 <services>
 
<!--Define a group for enforced password changing for users with-->
<!--expired passwords.-->
<!--Omit this group if you do not want to enforce password changes-->
  <group name="passwd-change">
   <selector>
    <user-password-change-needed />
   </selector>
  </group>

<!--Define a group for privileged users-->  
<!--Selector is used to define criteria for inclusion into the group-->
  <group name="admin">
   <selector>
    <user-privileged value="yes" />
   </selector>
  </group>

<!--Define a group for SFTP-only users-->    
<!--The members are listed in a separate group named staff-->    
  <group name="SFTP-users">
   <selector>
    <user-group name="staff" />
   </selector>
  </group>

<!--Define the enforced password changing policy-->
<!--Omit this group if you do not want to enforce password changes-->
    <rule group="passwd-change">
      <terminal action="deny" />
      <command application="/usr/bin/passwd" action="forced" />
      <tunnel-local action="deny" />
      <tunnel-remote action="deny" />
    </rule>

<!--Define what the privileged users are allowed to do-->  
  <rule group="admin" 
        idle-timeout="0">
   <terminal action="allow" />
   <subsystem type="sftp" 
              action="allow" 
              application="sft-server-g3" />
   <command action="allow" />
   <tunnel-local action="allow" />
   <tunnel-remote action="allow" />
  </rule>

<!--Define what the SFTP-only users are allowed to do-->    
  <rule group="SFTP-users">
   <terminal action="deny" />
   <subsystem type="sftp" 
              action="allow" 
              application="sft-server-g3"
              chroot="/home/%username%" />
   <command action="deny" />
   <tunnel-local action="deny" />
   <tunnel-remote action="deny" /> 
  </rule>

<!--Define that all actions are denied from the rest of the users-->      
  <rule>
   <terminal action="deny" />
   <subsystem type="sftp" 
              action="deny" 
              application="sft-server-g3" />
   <command action="deny" />
   <tunnel-local action="deny" />
   <tunnel-remote action="deny" />
  </rule>
 </services>
</secsh-server>

For information on Tectia Server behavior with expired passwords, see section Configuration File for Tectia Server in Tectia Server Administrator Manual.

<authentication action="allow">
  <auth-publickey />
</authentication>

<group name="admin">
  <selector>
    <user-privileged value="yes" />
  </selector>
</group>

<group name="SFTP-users">
  <selector>
    <user-group name="staff" />
  </selector>
</group>

Restricting Access to Folders

By default, file access by the user using the SFTP subsystem is restricted by the file system access controls. You can define more restrictions by activating chrooting.

Chrooting definitions are made in the ssh-server-config.xml configuration file.

Folder access can be further restricted by using the chroot attribute. The chroot attribute can be used with the subsystem, terminal, and command elements. For more information on chrooting, see Tectia Server Administrator Manual.

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

An example of chroot usage is shown below:

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

Here %username% will be replaced. For example, for user user7, the path would be /home/user7. During an SFTP session, user user7 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 Tectia Server Administrator Manual. If you want to deny OpenSSH SCP, you can disable all remote commands as is done in this example.

<rule group="admin">
  <terminal action="allow" />
...
</rule>

<rule group="SFTP-users">
  <terminal action="deny" />
...
</rule>

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