Permitir que apenas usuários específicos efetuem login via ssh em uma porta e outros para efetuar login por meio de outra porta

13

Eu tenho o seguinte caso de uso:

  • É necessário permitir que os usuários façam login de uma rede segura e confiável
  • e permitindo que dois (apenas dois) usuários móveis façam login remotamente em uma máquina Linux Centos.

Eu posso fazer o sshd rodar em diferentes portas, por exemplo:

  • por dentro, não há problema em fazê-lo funcionar em 22, já que não quero fazer com que eles se conectem em outras portas (atrapalha o script).
  • Para usuários móveis externos, executarei o sshd em uma porta diferente, digamos, porta X (maior segurança - esse é um tipo de configuração de pequeno escritório).

Para maior segurança, eu esperava configurar o sshd para permitir acesso apenas a usuários específicos na porta X (e configurar alguns alertas para que possamos saber quando os usuários estão efetuando login pela porta X).

No entanto, não consigo encontrar nenhuma configuração como essa na documentação do sshd. Se não houver uma solução como essa, é possível, pelo menos, acionar um script de shell para ser executado sempre que alguém concluir o login do sshd na porta X? Eu estava olhando a documentação do iptables para ver se ele poderia acionar um alerta quando o login do sshd estava lá, mas não consegui encontrar nada.

Entradas apreciadas

    
por doon 17.05.2013 / 11:58

3 respostas

12

A execução de SSH em uma porta alternativa não conta mais como segurança. Isso adiciona apenas um pouco de obscuridade e uma etapa adicional de complexidade para seus usuários. Ele adiciona zero obstáculos para pessoas que querem quebrar sua rede, que estão usando scanners de porta automatizados e não se importam com a porta em que estão sendo executados.

Se você deseja reforçar a segurança em um sistema que permite o SSH de entrada remoto baseado na Internet, controle seus usuários no sshd_config como @Anthon indicado e, em seguida, implemente a segurança diretamente no PAM.

Crie dois grupos, lusers e rusers . Adicione os usuários móveis remotos ao grupo rusers . Use o módulo PAM pam_succeed_if.so para permitir o acesso a esses usuários. Adicione linhas à configuração do seu pam para ssh:

account     sufficient  pam_succeed_if.so user ingroup lusers
account     sufficient  pam_succeed_if.so user ingroup rusers

Alguns módulos pam_succeed_if.so podem exigir que você use uma sintaxe ligeiramente diferente, como group = lusers .

Então, não apenas sshd está limitando os usuários que podem se conectar, mas no caso de um bug em sshd , você ainda tem a proteção que as restrições baseadas em PAM oferecem.

Um passo adicional para os usuários remotos é forçar o uso de ssh_keys com senhas. Assim, os usuários locais podem efetuar login com chaves ou senhas, mas os usuários remotos devem ter uma chave e, se você criar as chaves para eles, verifique se a chave possui uma senha associada. Assim, limitar o acesso a locais que realmente possuem a chave SSH e a frase secreta. E limitar potenciais vetores de ataque se a senha de um usuário for comprometida.

Em sshd_config :

altere 2 configurações:

ChallengeResponseAuthentication yes

e

PasswordAuthentication yes

para:

ChallengeResponseAuthentication no

e

PasswordAuthentication no

Portanto, o padrão é permitir agora apenas a autenticação por chave. Em seguida, para usuários locais, você pode usar a configuração match config para alterar o padrão para usuários locais. Supondo que sua rede privada local seja 192.168.1.0/24, adicione a sshd_config :

Match Address 192.168.1.0/24
PasswordAuthentication yes

Agora, os usuários locais podem se conectar com senhas ou chaves, e usuários remotos serão forçados a usar chaves. Cabe a você criar as chaves com frases secretas.

Como benefício adicional, você só precisa gerenciar um único sshd_config e só precisa executar o ssh em uma única porta, o que facilita seu próprio gerenciamento.

edit 2017-01-21 - Limitando o uso de arquivos authorized_keys .

Se você quiser ter certeza de que os usuários não podem apenas gerar uma chave ssh, e usá-la com um arquivo authorized_keys para login, você pode controlar isso definindo um local específico para o sshd procurar por chaves autorizadas.

Em /etc/ssh/sshd_config , altere:

AuthorizedKeysFile  %h/ssh/authorized_keys

para algo como:

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

Apontar para um diretório controlado no qual os usuários não têm permissão para gravar significa que eles não podem gerar sua própria chave e usá-la para solucionar as regras que você estabeleceu.

    
por 17.05.2013 / 13:41
7

Você pode adicionar algo assim ao seu /etc/ssh/sshd_config :

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

O texto acima assume que os usuários remotos permitidos são denominados mobileuser1 e mobileuser2 e que sua rede confiável é 10.0.0.0 com máscara de sub-rede 255.0.0.0.

Isso permite que os dois usuários móveis efetuem login de qualquer lugar e todos façam login a partir da rede confiável. Qualquer usuário que não corresponder a nenhum desses padrões (como o usuário foo efetuando login do remoto) terá acesso negado.

    
por 30.10.2015 / 00:06
2

Você pode fazer isso iniciando dois daemons ssh e dois arquivos sshd_config . Copie o existente (por exemplo, de /etc/ssh/sshd_config /etc/ssh/sshd_alt_config e na configuração de configuração alternativa (da página man para sshd_config :

Porto

Specifies the port number that sshd(8) listens on.  The default
is 22.  Multiple options of this type are permitted.  See also
ListenAddress

AllowUsers

This keyword can be followed by a list of user name patterns,
separated by spaces.  If specified, login is allowed only for
user names that match one of the patterns.  Only user names are
valid; a numerical user ID is not recognized.  By default, login
is allowed for all users.  If the pattern takes the form
USER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts.  The
allow/deny directives are processed in the following order:
DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

Você provavelmente deseja ter o registro ssh alternativo em um arquivo diferente e, por exemplo, siga o que está escrito nesse arquivo para notar tentativas de login aberrantes.

    
por 17.05.2013 / 12:39

Tags