É possível usar "sshd_config" para impedir o login root somente após o usuário efetuar login via ssh?

(Originalmente, a questão era mais rigorosa: isso é possível usando sshd_config? , mas desde então o OP a editou para permitir outras soluções "muito simples".)

Não, não é possível.

Depois que um usuário normal tiver permissão para uma sessão de shell normal, a sshd_configconfiguração não poderá impor nenhuma restrição aos comandos usados ​​nessa sessão.

Para conseguir o que deseja, você precisaria de algo que impedisse o sucesso da mudança para root se o usuário estivesse em uma sessão SSH. Simplesmente exigir que a sessão seja baseada em um dispositivo não pseudo-TTY (ou seja, uma porta serial ou um console virtual, como pode ser conseguido com pam_securetty) vai longe demais, pois também bloqueará o acesso root de logins da GUI local.

Isso exigiria algo como um módulo PAM para bloqueio sudoe suautenticação (e quaisquer outros métodos de troca de usuário baseados em PAM, se você os tiver) e algo mais para bloquear polkitmétodos de troca de usuário baseados em pkexec. O sshd_confignão tem nada a ver com nenhum desses mecanismos, portanto a resposta à sua pergunta deve ser “não”.

A sudolinha de configuração que você encontrou na internet:

username ALL=(ALL:ALL) ALL, !/bin/su, !/usr/bin/sudo -u root

tem um erro: bloquearia sudo sudo -u root [...], mas permitiria plain sudo -i, sudo bashou qualquer outro meio de obter root.

Em geral, qualquer tentativa de " permitir todos os comandos, exceto (um número limitado de comandos 'ruins') " provavelmente será contornada trivialmente, já que usuários regulares do shell podem normalmente fazer suas próprias cópias de binários de comandos padrão sob nomes de sua própria escolha , permitindo a execução deles sudopor username ALL=(ALL:ALL) ALLparte da configuração.

A maneira mais direta de conseguir o que deseja seria bloquear o acesso root por trás de alguma forma de token de autenticação física, como um cartão inteligente ou Yubikey. Um usuário remoto não pode conseguir o efeito de conectar um token de autenticação ao sistema físico. Também forneceria um segundo fator de autenticação, o que aumentaria significativamente a segurança do seu acesso root.

É possível, mas não tenho certeza de quão fácil é. No Linux (e praticamente apenas no Linux, e não em qualquer outro tipo Unix), existe um sinalizador chamado "no new privilégios" , que efetivamente desativa os binários setuid para o thread de chamada e todos os seus descendentes, irrevogavelmente. Não consegui encontrar nada na documentação do OpenSSH que sugerisse que o SSH possa habilitá-lo para você, então provavelmente você terá que fazer isso manualmente. Isso consistiria em escrever um pequeno programa C que é executado prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);e então faz algo como execl("/bin/bash", "-bash", (char*) NULL)executar o shell do usuário (que pode ou não ser bash, então você pode usar getpwuid(getuid())->pw_shellpara procurar o shell correto - verificação de erros omitida por questões de brevidade). Você então definiria ForceCommand para seu programa, para que os usuários sejam sempre forçados a invocar esse wrapper.

Isso interromperá a capacidade dos usuários de executar comandos arbitrários, passando-os como um argumento extra para o SSH, o que ocasionalmente é útil. Se você deseja oferecer suporte a esse caso de uso, use getenvpara procurar o valor da variável de ambiente SSH_ORIGINAL_COMMANDe executá-lo se não estiver vazio. Observe que o SSH normalmente executa comandos executando o shell de login do usuário com o -csinalizador (seguido pelo comando solicitado), então você também deve fazer isso.

Também não é totalmente infalível. Programas como run0 funcionam solicitando a um daemon privilegiado (neste caso, systemd) que execute comandos em nome de um usuário sem privilégios, sem usar setuid, portanto, "sem novos privilégios" não tem efeito sobre tal comando. Se você estiver executando o systemd (ou qualquer coisa parecida com o systemd), você precisará tomar as medidas apropriadas para bloquear essa funcionalidade separadamente (por exemplo, colocando a sessão SSH do usuário dentro de algum tipo de contêiner ou removendo seus privilégios para iniciar e parar unidades de serviço por meio da CLI do systemd).

Finalmente, esteja ciente de que este é um martelo muito grande. Ele desativa completamente o sudo e qualquer coisa que funcione como sudo (exceto run0 conforme discutido acima). Não há seletividade alguma - esta é uma bandeira de tudo ou nada. Mas pelo lado positivo, isso também significa que (quase) não há lacunas com as quais você precise se preocupar. Por exemplo, você não precisa forçar os binários interativos a algum tipo de modo "restrito" que impeça o usuário de obter um shell (como geralmente é necessário com restrições mais seletivas do sudo).