Segurança de conexão SSH perpétua e implicações práticas

Question

Eu tenho usado o desktop Linux há muitos anos, mas raramente entro em seus aspectos de rede. Eu corro um servidor de arquivos pessoal (principalmente executando owncloud no Ubuntu 14.04), e para executar manutenção regular e verificação de log eu ssh na máquina. Eu me vejo deixando uma conexão ssh aberta da minha área de trabalho para o servidor de arquivos de tempos em tempos, simplesmente por convenção.

Minha pergunta é dupla:

1. {Quais são} / {existem} implicações de segurança de deixar uma conexão ssh perpetuamente aberta?

2. {Quais são} / {existem} implicações de praticidade? Ou seja uso de rede, etc ...

   Eu percebo que, do ponto de vista do tráfego, haverá um pacote ocasional de 'keep alive' para manter a conexão, mas, caso contrário, não espero muita sobrecarga. Corrigir?

Answer 1

{What are} / {are there} security implications of leaving a ssh connection perpetually open?

A chave de sessão é renegociada periodicamente, portanto, não há muitos problemas de confidencialidade. Você pode configurar o tempo entre renegociações com RekeyLimit (segundo parâmetro para essa diretiva) se isso for uma preocupação para você.

Como shadowbq meio que alude, os problemas de segurança são basicamente os mesmos que rodar qualquer outro cliente de controle remoto perpetuamente. Isso significa que aumenta potencialmente a superfície de ataque da sua rede interna de uma forma que depende da segurança física da estação de trabalho.

{What are} / {are there} practicality implications? I.e. network usage, etc...

Próximo a zero. O servidor e o cliente ocasionalmente re-digitarão a sessão, mas fora dela, são apenas os keepalives normais de nível SSH e de nível TCP que são enviados. Provavelmente estamos falando de alguns KB de pacotes de rede ao longo de meia hora.

    

Answer 2

1. Deixar a conexão estabelecida representa uma ameaça à segurança durante essas situações

   • Você tem túneis reversos / portas encaminhadas que comprometem as restrições de rede do Firewall corporativo.
   • Suas sessões podem ser monitoradas para taxas de transferência de dados, mas não mais que uma conexão VPN SSL
   • Você tem outros serviços que podem ser comprometidos, levando a um pivô para o servidor de destino (ou seja, hospedagem de servidores da Web externos, conexões do tmux, etc.)
   • Segurança física do computador, teclado ou recursos KVM remotos.
   • Usuários secundários na área de trabalho. (TTY sem garantia, etc.)
   • Ter chaves de identidade privada SSH não seguras.

2. Existem dois tipos de keep alives enviados durante as comunicações SSH. Cada um desses é sintonizável. Tráfego mínimo é enviado para manter os keep alives.