Method #1 - Using timeouts via SSHD/SFTPD
If the connections are over SSH you can set these settings on the SSHD's side in the config file
ClientAliveInterval 30 ClientAliveCountMax 5
Where these settings have the effect:
ClientAliveInterval: Sets a timeout interval in seconds (30) after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. This option applies to protocol version 2 only.
ClientAliveCountMax: Sets the number of client alive messages (5) which may be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session.
To get 10 minutes you'll need to adjust the times accordingly, perhaps like this:
ClientAliveInterval 120 ClientAliveCountMax 5
Method #2 - Using cutter
If the above methods do not work then it's entirely possible that the client is making use of a keep-alive which is artificially propping up the low trafficked connection. If this is your situation then your limited to what actions you can take to disconnect these otherwise idle connections.
One method would be to develop a cronjob that would watch for connections that have been idle for a particular period of time, say 10 minutes in your scenario.
Once this script has detected one of these connections, you could use a command such as
cutter to tell the client to disconnect, against their will.
$ cutter <ip> <port>
$ cutter 192.168.1.20 22
NOTE: Cutter should be in most of the major distros' repositories. I was able to install it on Fedora/CentOS/RHEL as well as Debian/Ubuntu in this manner.