Bloqueie completamente a conta de usuário no servidor, incluindo ssh

A documentação, man usermod, fornece a solução recomendada:

-L, --lockBloqueie a senha de um usuário. Isso coloca um !na frente da senha criptografada, desabilitando efetivamente a senha. Você não pode usar esta opção com -pou -U.

Nota: se você deseja bloquear a conta (não apenas o acesso com senha), você também deve definir EXPIRE_DATEo 1.

E depois

-e, --expiredate EXPIRE_DATEA data em que a conta de usuário será desativada. A data é especificada no formato YYYY-MM-DD.

Um argumento vazio EXPIRE_DATEdesabilitará a expiração da conta.

Então, transformando isso em um exemplo real

usermod -L -e 1 someuser     # Lock
usermod -L -e '' someuser    # Unlock

Se você tiver uma data de expiração padrão configurada, /etc/default/useraddpoderá incluir seu valor - se houver - como parte do processo de desbloqueio:

usermod -U -e "$( . /etc/default/useradd; echo "$EXPIRE")" someuser

Os trabalhos agendados crontambém são desabilitados para um usuário com uma conta expirada, mas não apenas para uma conta bloqueada. As mensagens de erro journalctl -u cronmostram o nome da conta do usuário expirado (neste caso test2):

Apr 30 11:47:01 pi CRON[26872]: pam_unix(cron:account): account test2 has expired (account expired)
Apr 30 11:47:01 pi cron[472]: Authentication failure
Apr 30 11:47:01 pi CRON[26872]: Authentication failure

Os trabalhos agendados com atpermanecem não tentados. (Não está claro para mim se eles serão executados quando passarem da data de vencimento; empiricamente, parece que não.)

Outros processos já em execução na conta bloqueada e expirada permanecem inalterados e continuam em execução.

Depois de emitir "usermod -L user" você pode negar o acesso ssh adicionando esta linha ao final do arquivo /etc/ssh/sshd_config :

DenyUsers user

Ou você pode criar um grupo para essa finalidade para poder negar o login ssh adicionando usuários ao grupo:

groupadd deny-ssh
usermod -a -G deny-ssh user

E adicione o grupo ao final do arquivo /etc/ssh/sshd_config :

DenyGroups deny-ssh

Após cada alteração no arquivo /etc/ssh/sshd_config , certifique-se de recarregar o daemon sshd para aplicar as alterações:

systemctl reload sshd

O comando reload carregará as novas configurações e manterá todas as sessões ssh existentes abertas.

Como alternativa, você pode alterar o shell do usuário para que, mesmo que ele faça login, ele não receba um shell:

usermod --shell /usr/sbin/nologin user

Eu poderia recomendar a criação de um script bash simples que fará todos os itens acima com apenas um comando.

deny-logon.sh:

#!/bin/bash

#Lock user account
usermod -L $1

#Deny SSH connections
usermod -a -G deny-ssh $1

#Remove user Shell
usermod --shell /usr/sbin/nologin $1

#Reload sshd
systemctl reload sshd

Agora você simplesmente tem que executar o script assim:

./deny-logon.sh user

E fará automaticamente todas as alterações acima para o "usuário".

EDIT: A solução @roaima é a mais correta, expirar uma conta desabilita todos os acessos a ela e deve ser feito se você quiser impedir que um usuário faça login.

Você deve ser capaz de desabilitar ssh-logins para usuários adicionando seus nomes de usuário ou grupos em

/etc/ssh/sshd_config

sob a configuração DenyUserse/ou DenyGroup.

Veja man 5 sshd_config.

Não se esqueça HUPdo sshd.

Para impedir adequadamente o acesso de um usuário em um servidor SSH, a solução correta é modificar a configuração do SSHD para que o acesso seja explicitamente negado usando as configurações DenyUserse/ou DenyGroups. Normalmente, sugiro usar DenyGroupse criar um grupo dedicado para essa finalidade, ao qual você adiciona qualquer pessoa que não deveria ter acesso SSH.

Para bloquear totalmente a conta, você também precisa bloquear a senha, configurá-la como expirada (ambos usando usermod) e alterar o shell de login para /sbin/nologinque outros mecanismos de login não os deixem entrar. Você pode precisar fazer ainda mais do que isso em alguns casos também (por exemplo, se o servidor executar o Samba e o usuário tiver acesso a compartilhamentos de arquivos por meio do SMB, você provavelmente precisará bloquear sua conta do Samba também usando smbpasswd).

Por que apenas bloquear a conta usermodnão é suficiente?

Isso se resume ao fato de que uma conta é 'bloqueada' no sentido tradicional do UNIX, fazendo com que não importa qual senha o usuário tente usar, ela nunca corresponderá ao que está no banco de dados de senhas. Isso significa, muito importante, que bloquear a conta afeta usermod apenas os serviços que estão autenticando no banco de dados de senhas do sistema (em um sistema Linux moderno, isso significaria os serviços configurados para usar o pam_unixmódulo PAM para autenticação ).

No entanto, o SSHD só autentica no banco de dados de senhas do sistema se a senha ou o mecanismo de autenticação de resposta de desafio estiver sendo usado. A autenticação de chave pública, bem como quaisquer outros mecanismos de autenticação (como GSSAPI ou s/key) envolvem apenas o banco de dados de senhas do sistema para verificar se a conta existe, portanto, geralmente funcionarão bem com uma conta bloqueada.

Por que definir o shell de login como /sbin/nologinnão é suficiente?

Isso tem a ver com o fato de que existem várias maneiras de acessar um sistema como uma conta de usuário específica que não tem nada a ver com um shell de login.

O mais relevante aqui é que SFTP, SCP e SSH com um comando explicitamente especificado não invocam um shell de login. Isso significa que mesmo com o shell de login definido como /sbin/nologin, você geralmente pode obter um shell de trabalho em um sistema como usuário executando ssh -t user@host /bin/sh( -té necessário solicitar explicitamente a alocação de pseudoterminal, que por sua vez é necessária para obter algumas coisas, como sudoou vimpara funcionam corretamente a partir do shell resultante), e quase sempre você ainda pode usar SFTP e SCP para mover arquivos.

Outro exemplo disso seria usar sudo -u user /bin/shpara obter um shell de trabalho como um determinado usuário de uma sessão existente no sistema como um usuário diferente. Isso funcionará mesmo se o shell de login do usuário de destino estiver definido como /sbin/nologin, embora se a conta também estiver bloqueada usando usermod, você terá que executá-la como usuário root (pelo menos, em qualquer sudoconfiguração padrão).

Bloquear a conta é a maneira correta. Você também pode querer remover o arquivo authorized_keys para derrotar o SSH.

Lembre-se de que existem outras maneiras além do SSH de logon.

Fazer qualquer coisa com rotinas "*rc" é desajeitado, mas comumente usado para contas "só sftp" se for uma conta de utilitário, digamos sftp ou SCP.

Mas !password é melhor do que mudar sua senha se a restauração for necessária.

Como sempre, mantenha backups e com segurança.

Se você não quiser confiar em suposições sobre como um software diferente tratará o estado bloqueado ou expirado no shadowarquivo, um grande martelo para bloquear completamente a conta de usuário é remover sua linha do passwdarquivo (mantendo um backup em outro lugar). Com essa alteração, não há mais mapeamento do nome de usuário para o uid ou diretório inicial, portanto, nada (sshd ou outro) pode procurar o nome de usuário, encontrar o diretório inicial e o authorized_keysarquivo (ou similar) e agir sobre ele.