Método # 1 - Usando timeouts via SSHD / SFTPD
Se as conexões forem por SSH, você pode definir essas configurações no lado do SSHD no arquivo de configuração /etc/ssh/sshd_config .
ClientAliveInterval 30
ClientAliveCountMax 5
Onde essas configurações têm efeito:
-
ClientAliveInterval: Define um intervalo de tempo limite em segundos (30) após o qual, se nenhum dado tiver sido recebido do cliente, o sshd enviará uma mensagem pelo canal criptografado para solicitar uma resposta do cliente. O padrão é 0, indicando que essas mensagens não serão enviadas ao cliente. Esta opção aplica-se apenas à versão 2 do protocolo. -
ClientAliveCountMax: Define o número de mensagens ativas do cliente (5) que podem ser enviadas sem que o sshd receba nenhuma mensagem do cliente. Se esse limite for atingido enquanto as mensagens do cliente ativo estiverem sendo enviadas, o sshd desconectará o cliente, encerrando a sessão.
Para obter 10 minutos, você precisará ajustar os horários de acordo, talvez assim:
ClientAliveInterval 120
ClientAliveCountMax 5
Método # 2 - Usando o cortador
Se os métodos acima não funcionarem, é perfeitamente possível que o cliente esteja fazendo uso de um keep-alive que esteja artificialmente sustentando a conexão com tráfego baixo. Se esta é a sua situação, então você está limitado a quais ações você pode tomar para desconectar essas conexões inativas.
Um método seria desenvolver um cronjob que vigiaria conexões que ficaram inativas por um determinado período de tempo, digamos, 10 minutos em seu cenário.
Quando esse script detectar uma dessas conexões, você poderá usar um comando como cutter para informar ao cliente que ele se desconecte, contra sua vontade.
$ cutter <ip> <port>
Exemplo
$ cutter 192.168.1.20 22
NOTA: O Cutter deve estar na maioria dos repositórios das principais distribuições. Eu pude instalá-lo no Fedora / CentOS / RHEL assim como no Debian / Ubuntu desta maneira.
Depurando as conexões
O @Gilles trouxe um excelente ponto nos comentários sob o seu Q que conexões ociosas realmente não deveriam estar causando nenhuma carga de CPU. O fato de que todos esses sftp-server processos estão causando o que eu consideraria é que uma carga significativa (20-30%) em top parece indicar que algo está acontecendo.
Para começar, usaria strace e conecte-se a um dos processos sftp-server para ver o que está acontecendo. Por exemplo, para conectar-se ao PID 17247:
$ sudo strace -p 17247
Veja se está realmente fazendo alguma coisa. Realmente não deveria ser. Você também pode usar tcpdump ou wireshark para monitorar o tráfego de rede indo e voltando entre o Nautilus e o sftp-server .