### 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 `/etc/ssh/sshd_config`.

    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>

### Example

    $ cutter 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.

### Debugging the connections
@Gilles brought up an excellent point in the comments under your Q that idle connections should really not be causing any CPU load. The fact that all these `sftp-server` processes are causing what I would consider is significant load (20-30%) in `top` would seem to indicate that something is going on.

To start I would use `strace` and connect to one of the `sftp-server` processes to see what it's up to. For example to connect to PID 17247: 

    $ sudo strace -p 17247

See if it's actually doing anything. It really shouldn't be. You could also use `tcpdump` or `wireshark` to monitor the network traffic going back and forth between Nautilus and `sftp-server` as well.

### References
- [Open SSH Server connection drops out after few or N minutes of inactivity][1]

  [1]: http://www.cyberciti.biz/tips/open-ssh-server-connection-drops-out-after-few-or-n-minutes-of-inactivity.html