Desativar shell do usuário por motivos de segurança

58

Temos várias contas de usuário que criamos para tarefas automatizadas que exigem permissões refinadas, como transferência de arquivos entre sistemas, monitoramento etc.

Como bloqueamos essas contas de usuário para que esses "usuários" não tenham shell e não possam fazer login? Queremos evitar a possibilidade de alguém fazer o SSH como uma dessas contas de usuário.

— Suman
fonte

63

Você pode usar o usermodcomando para alterar o shell de login de um usuário.

usermod -s /sbin/nologin myuser

ou

usermod -s /usr/sbin/nologin myuser

Se o seu sistema operacional não fornecer / sbin / nologin, você poderá definir o shell como um comando NOOP, como / bin / false:

usermod -s /bin/false myuser

— jordanm
fonte

1

/bin/falseparece mais comum que /bin/true.

— Jw013 07/11

@ jw013 Atualizo minha resposta, mas ambos devem funcionar bem.

— Jordanm #

1

Note que no Debians, nologinna verdade , pode ser encontrado em/usr/sbin/nologin

— xebeche

esta foi minha primeira idéia, infelizmente o uso 'válido' de algumas contas de usuário é desabilitado ao definir #nologin

— Javier

2

@ jw013 Na verdade, eu tenho o /usr/local/bin/maybeque /dev/urandomseleciona entre os dois. Talvez eu deva usá-lo: D

— hegez 4/17/17

21

Alterar o shell de logon não impede necessariamente a autenticação dos usuários (exceto em alguns serviços que verificam se o shell do usuário é mencionado em /etc/shells).

As pessoas ainda podem se autenticar nos vários serviços que seu sistema fornece aos usuários unix e ainda podem estar autorizadas a executar algumas ações, embora provavelmente não executem diretamente comandos arbitrários.

Alterar o shell para /bin/falseou /usr/sbin/nologinimpedirá que eles executem comandos nos serviços que podem ser usados para executar comandos (login do console, ssh, telnet, rlogin, rexec ...), afetando a autorização apenas para alguns serviços.

Por sshexemplo, isso ainda lhes permite fazer o encaminhamento de porta.

passwd -ldesativará a autenticação por senha, mas o usuário ainda poderá usar outros métodos de autenticação (como authorized_keysem ssh).

No pamLinux, pelo menos, você pode usar o pam_shellsmódulo para restringir a autenticação ou autorização aos usuários com um shell permitido (aqueles mencionados em /etc/shells). Pois ssh, você desejará fazê-lo no accountnível de autorização ( ) como para sshdusos de autenticação pam , além de outros métodos de autenticação (como authorized_keys), ou poderá fazê-lo com sshd_configdiretivas em /etc/ssh/sshd_config(como AllowUserse amigos).

Entretanto, tenha em atenção que adicionar algumas restrições na autorização global de pam impedirá a execução de crontrabalhos como esses usuários.

— Stéphane Chazelas
fonte

Obrigado. Então, o que você recomendaria, considerando o seguinte esquema: Preciso criar um usuário que precise acessar sua pasta pessoal por meio de sftp ou sshfs, mas ele não deve conseguir fazer login com um shell. É mesmo possível ? Eu caí como módulos PAM pode ser a solução Goto, mas eu não entendo tudo:|

— Stphane

@ Stphane você pode dar uma olhada no rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html

— Hart Simha

4

Você edita o /etc/passwdarquivo e altera o shell do usuário de /bin/bashou /bin/shpara/sbin/nologin

— Mark Cohen
fonte

8

A resposta está correta, mas a edição manual / etc / passwd nunca deve ser recomendada.

— Jordanm #

3

Por quê? Isso é algo que estamos fazendo há tanto tempo que eu sou um administrador profissional do sistema. (cerca de 20 anos agora) De fato, nem todas as distribuições linux / unix têm ferramentas para modificar / etc / passwd ou / etc / group .. A menos que você use algo como Yast ou Smit, que são ferramentas que armazenam em cache as configurações e sobrescrevem não há nenhum dano na edição manual.

— Mark Cohen

6

É muito mais fácil cometer um erro "interrompe o login de todos" editando manualmente, em vez de um único usuário.

— Jordanm #

2

@ Jordanm: existe o vipwque impede esse tipo de erro.

— Eudoxo

4

Primeiro, desative a senha, usando passwd -l username.

Observe também na manpágina para passwda opção -l:

   -l, --lock
       Lock the password of the named account. This option disables a password by changing it to a value which matches no
       possible encrypted value (it adds a Â´!Â´ at the beginning of the password).

       Note that this does not disable the account. The user may still be able to login using another authentication token
       (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's
       expire date to Jan 2, 1970).

       Users with a locked password are not allowed to change their password.

— mdpc
fonte

1

Isso pode não ser desejável. Eles podem precisar de uma senha na conta do sistema para acessar o email, por exemplo.

— Jordanm #

1

Alguns sistemas de email permitem o uso de seus próprios mecanismos de senha. Eu uso o Dovecot e o Exim com uma senha apenas para email. Isso permite o uso de webmail em servidores que eu não usaria a senha do meu sistema. Os domínios de email virtual exigem sua própria senha, pois não estão acoplados ao sistema de senha dos servidores.

— BillThor

2

Você pode usar o comando chsh:

~# chsh myuser

Insira novos detalhes do shell quando solicitado:

Login Shell [/bin/sh]: /bin/nologin

Ou versão mais curta:

~# chsh myuser -s /bin/nologin

— Vamos conversar
fonte

0

Para impedir que o usuário faça logon e até autenticação através do ssh, que permite o encaminhamento de porta (como descrito aqui Stephane), modifico o usuário para ser semelhante ao nobodyusuário do sistema :

autenticação de senha bloqueada em /etc/shadow(com *ou !!no campo apropriado)
shell desativado /etc/passwd(por exemplo, /sbin/nologinno campo apropriado)
dir de origem somente leitura em /etc/passwd(por exemplo, /no campo apropriado)

— pressione o botão
fonte