OpenSSHsshd_config

Palavras-chave de configuração corretas desde OpenSSH 9.2 (Debian 12)

O OpenSSH 9.2 (2 de fevereiro de 2023) introduziu novos recursos para sessões inativas.

• sshd(8): adiciona suporte para tempos limite de inatividade do canal através de uma nova ChannelTimeoutdiretiva sshd_config(5). Isso permite que canais que não viram tráfego em um intervalo configurável sejam fechados automaticamente. Diferentes tempos limite podem ser aplicados aos canais de encaminhamento de sessão, X11, agente e TCP.

• sshd(8): adicione uma UnusedConnectionTimeoutopção sshd_config para encerrar conexões de clientes que não possuem canais abertos por um período de tempo. Isso complementa a opção ChannelTimeout acima.

Durante as oito horas nesta questão, por exemplo,

ChannelTimeout *=8h
UnusedConnectionTimeout 1m

Onde:

• O *=8hmonitora todos os canais separadamente. Se você quiser que a atividade em qualquer canal redefina o tempo limite, use a palavra-chave especial global=8h.
• O valor UnusedConnectionTimeouté definido para um minuto para encerrar a conexão logo após o último canal ter sido fechado.

Para OpenSSH <9.2, isso deve ser feito por outros meios.

As palavras-chave de configuração usadas são para sessões que não respondem

O ClientAliveIntervalnão monitora a inatividade , mas sim se o cliente ainda está respondendo .

Define um intervalo de tempo limite em segundos após o qual, se nenhum dado for recebido do cliente, o sshd(8) enviará uma mensagem através do canal criptografado para solicitar uma resposta do cliente . O padrão é 0, indicando que essas mensagens não serão enviadas ao cliente.

A documentação para ClientAliveCountMaxpode ajudar a entender isso:

Se ClientAliveIntervalestiver definido como 15 e ClientAliveCountMaxfor deixado no padrão, os clientes SSH que não responderem serão desconectados após aproximadamente 45 segundos. Definir um zero ClientAliveCountMaxdesativa o encerramento da conexão.

📜 Uma nota histórica: antes do OpenSSH 8.2 (14 de fevereiro de 2020), ele ClientAliveCountMaxfuncionava de maneira diferente com o 0, tendo o efeito colateral de que poderia ter sido usado para encerrar conexões ociosas. Do registro de alterações:

Correções de bugs

• sshd(8): make ClientAliveCountMax=0have sensible semântica: agora desabilitará totalmente a eliminação da conexão, em vez do comportamento atual de encerrar instantaneamente a conexão após o primeiro teste de atividade, independentemente do sucesso. bz2627

⚠️ No entanto, esta instrução enganosa foi repetida em toda a Internet :

• Geeks for Geeks : Desconectando conexões SSH inativas no Linux
• Vivek Gite no nixCraft : Linux/UNIX faz logout automático de usuários BASH/TCSH/SSH após um período de inatividade
• Hayden James no Linuxblog.io : Como eliminar sessões SSH inativas
• Dicas do KGIII no Linux : Desative sessões SSH inativas
• Aaron Kili no Techmint : Como desconectar conexões SSH inativas ou ociosas no Linux
• Satish Kumar no ponto de tutoriais : Como desconectar conexões SSH inativas ou ociosas no Linux?

Destes, apenas o Gite tinha o ClientAliveCountMax=0que poderia ter funcionado antes de 2020, mas isso conta? Afinal, o artigo provavelmente foi escrito em 2021... Me pergunto se alguém leu a documentação ou está ocupado copiando e colando postagens de outros blogs. 🤦‍♂️

Discussão aprofundada sobre alternativas

Scripting – tome cuidado para detectar a inatividade corretamente

Hayden James dá um exemplo de automatização do processo com um script . No entanto, usar esse script é perigoso, pois pode encerrar sessões SSH que estão em uso ativo. O script obtém o "tempo ocioso" de ps -eo pid,etimes,commonde etimesnão mostra o tempo ocioso do processo, mas sim o tempo total que ele esteve em execução. De ps(1) :

ESPECIFICADORES DE FORMATO PADRÃO

CÓDIGO	CABEÇALHO	DESCRIÇÃO
às vezes	DECORRIDO	tempo decorrido desde que o processo foi iniciado, em segundos.

Satish Kumar sugere usar whopara lista de usuários ativos e a quinta coluna w -hpara detectar inatividade. No entanto, este script também tem algumas falhas:

• A quinta coluna não contém os segundos como um número inteiro, mas um valor de string 2.00scomo 7:51mou 5days. O [[ "$idle" -gt "1800" ]];não analisa isso corretamente.
• Se a comparação fosse possível, o script mataria todos os processos do usuário...
  • ...caso o usuário não tenha digitado nada em nenhuma das sessões.
  • ...incluindo multiplexadores de terminal ( screen, tmux) e outros processos que se destinam a viver fora de uma sessão SSH ativa.

A detecção da inatividade deverá ser bem mais precisa, assim como a seleção do processo a ser eliminado.

Esta abordagem poderia funcionar:

1. Pegue as sessões diretamente da segunda coluna do arquivo who.
2. Use statpara obter o horário do último acesso do dispositivo TTY (veja a resposta do Celada ).

   who -s | awk '{ print $2 }' | (cd /dev && xargs stat -c '%n %U %X')
   

   Isso pode ser convertido diretamente em idade em segundos:

   who -s | awk '{ print $2 }' | (cd /dev && xargs stat -c '%n %U %X') \
     | awk '{ print $1"\t"$2"\t"'"$(date +%s)"'-$3 }'
   

3. Use pgreppara localizar sshdprocessos para os TTYs ou pkillpara eliminá-los.

   user=$(echo "$line" | awk '{print $1}')
   tty=$(echo "$line" | awk '{print $2}')
   age=$(echo "$line" | awk '{print $3}')
   pgrep -f "sshd: ${user}@${tty}"
   

Tudo junto (mais completo find-inactive-ssh-sessions.shem oh2fih/ Misc-Scripts ):

#!/bin/bash
MAX_IDLE=28800  # default 8 hours
KILL=0          # set 1 to kill instead of list

# Get TTYs with the seconds since the last access time
TTYS=$(
  who -s \
    | awk '{ print $2 }' \
    | grep -ve "^:"
  )
if [ "$TTYS" = "" ]; then
  exit 0
fi

TTY_AGES=$(
  echo "$TTYS" \
    | (cd /dev && xargs stat -c '%U %n %X') \
    | awk '{ print $1"\t"$2"\t"'"$(date +%s)"'-$3 }'
  )

# Get sshd processes of the TTYs; list or kill
while IFS= read -r line ; do 
  user=$(echo $line | awk '{print $1'})
  tty=$(echo $line | awk '{print $2'})
  age=$(echo $line | awk '{print $3'})
  if (( $age > $MAX_IDLE )); then
    if (( KILL == 1 )); then
      pkill -f "sshd: ${user}@${tty}"
    else
      pgrep -f -a "sshd: ${user}@${tty}"
    fi
  fi
done <<< "$TTY_AGES"

Recursos integrados em shells

Como menciona Vivek Gite , os shells possuem recursos para desconectar automaticamente o usuário após um período de inatividade. Isso pode funcionar se não houver necessidade de forçar o logout, pois o usuário poderá alterar essas configurações.

• TMOUTvariável de ambiente para bash, zsh& ksh.

  export TMOUT=28800
  

• autologoutconfigurando em tcsh& csh.

  set -r autologout 28800
  

Se você configurá-los através, por exemplo, de /etc/profile.d/, eles afetarão todas as sessões. No entanto, você também pode usar recursos sshd_configpara configurá-los: SetEnv& ForceCommand. Por exemplo,

SetEnv TMOUT=28800

Match Group cshusers
    ForceCommand set -r autologout 28800

De onde vem a recomendação?

O conselho provavelmente é baseado, por exemplo, no NIST 800-171 Revisão 2 :

3.1.11 Encerrar (automaticamente) uma sessão de usuário após uma condição definida.

DISCUSSÃO

Este requisito aborda o encerramento de sessões lógicas iniciadas pelo usuário, em contraste com o encerramento de conexões de rede associadas a sessões de comunicação (ou seja, desconexão da rede). Uma sessão lógica (para acesso local, de rede e remoto) é iniciada sempre que um usuário (ou processo agindo em nome de um usuário) acessa um sistema organizacional. Essas sessões de usuário podem ser encerradas (e, portanto, encerrar o acesso do usuário) sem encerrar as sessões de rede. O encerramento da sessão encerra todos os processos associados à sessão lógica de um usuário, exceto aqueles processos criados especificamente pelo usuário (ou seja, o proprietário da sessão) para continuar após o término da sessão. Condições ou eventos desencadeadores que exigem o encerramento automático da sessão podem incluir períodos de inatividade do usuário definidos pela organização, respostas direcionadas a certos tipos de incidentes e restrições de horário no uso do sistema.

Você deve decidir o que é mais importante para você: impedir que alguém use a conexão sem permissão ou a confiabilidade das conexões de gerenciamento. O uso não autorizado poderia ser evitado por outros meios? Por exemplo, as conexões SSH poderiam ser limitadas apenas aos computadores da empresa e os computadores da empresa poderiam ser forçados a serem bloqueados por inatividade?