Estou executando a versão Windows do OpenSSH (instalado por meio da GUI de gerenciamento de recursos opcionais) há algum tempo em uma caixa de servidor Windows 10. Até agora, o SSH só foi usado na LAN, mas estou trabalhando para fortalecer minha configuração SSH para expô-la à WAN.
Além de se fortalecer sshd_config, o IE permite apenas um usuário específico e limitado quando a conexão é da WAN, estive pensando no serviço em si. Eu sei que muitas vezes é uma boa prática executar serviços em contas de usuários específicas. (embora minha experiência aqui seja muito limitada)
Atualmente, sshd.exeparece rodar na SYSTEMconta, e já tinha pensado em mudar isso, já que SYSTEMé muito privilegiado. Porém, percebo que quando um usuário se conecta via SSH, outro sshd.exeprocesso é criado, sendo executado sob essa conta de usuário. Isso significa que não há problema em sshd.exeexecutar o processo 'inicial' como SYSTEM?
Além disso, percebo que quando um usuário se conectou, mas ainda não se autenticou (com autenticação de senha, será desabilitado na WAN), uma sshd.exeinstância é criada em execução sob o usuário sshd_644. Alguém pode explicar o que é essa conta de usuário?
Qualquer contribuição será apreciada.
Sim, e é inevitável – o trabalho real do sshd é inerentemente altamente privilegiado; afinal, ele precisa ter privilégios para se tornar qualquer usuário para poder processar logons. (E não apenas passando pelo processo padrão do Windows para logons 'interativos', pois isso requer a senha - a autenticação do par de chaves SSH não pode usar isso, portanto, necessariamente coloca total confiança no serviço sshd para verificar as credenciais e, em seguida, personificar sua conta, que é uma das coisas com maior privilégio que um serviço pode fazer.)
OpenSSH vem de um ambiente Unix, onde o serviço sshd quase sempre é executado como 'root', uma conta que tem por padrão privilégios ainda mais altos do que SYSTEM no Windows. (Por exemplo, recursos como ignorar permissão de arquivo precisam ser ativados deliberadamente no Windows, mas estão ativos por padrão para root em sistemas do tipo Unix.) Ele foi projetado para sobreviver em tal ambiente (veja a próxima seção), e será provavelmente sobreviverá como SYSTEM no Windows.
É possível executar o sshd com uma conta limitada, mas isso significa que você só pode fazer login na mesma conta (já que o sshd não pode mais se tornar outra pessoa) – e também anula algumas das proteções que o OpenSSH faria. teria feito o contrário, já que agora expõe a mesma conta a bugs de pré-autenticação que de outra forma estariam confinados à conta 'sshd'.
Esse é o mecanismo de “separação de privilégios” que o OpenSSH implementa para compensar sua necessidade de executar com privilégios – na verdade, ele não permite que o processo principal e privilegiado lide com logins; ele gera um processo sem privilégios que pode fazer muito pouco, exceto falar com o cliente ou comunicar os resultados ao processo pai. (Linux e BSDs têm vários mecanismos, como seccomp, para limitar o que o processo pode fazer além da barreira padrão de "conta de usuário separada"; o Windows também tem, até certo ponto, mas não sei se o OpenSSH os usa - provavelmente depende muito em qual porta OpenSSH Windows você instalou.)
Este padrão é comumente visto em serviços Linux que precisam fazer algumas coisas privilegiadas, por exemplo, um servidor de e-mail seria iniciado na conta root, mas na realidade teria um processo supervisor rodando como root e 3-5 processos lidando com tarefas diferentes sob contas limitadas (muitas vezes múltiplas).