Permitindo que somente usuários específicos façam login via ssh em uma porta e outros façam login através de outra porta

Eu tenho o seguinte caso de uso:

• Necessidade de permitir que os usuários efetuem login a partir de uma rede segura e confiável
• e, em seguida, permitindo que dois (apenas dois) usuários móveis efetuem login remotamente em uma máquina Linux Centos.

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

• por dentro, não há problema em fazê-lo funcionar em 22, pois não quero que eles se conectem em outras portas (atrapalha o script).
• Para usuários móveis externos, executarei o sshd em uma porta diferente, por exemplo, na porta X (maior segurança - este é um tipo de instalação para pequenos escritórios).

Para aumentar a segurança, eu esperava configurar o sshd para permitir o 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 esta na documentação do sshd. Se não houver uma solução como essa, é pelo menos possível ativar 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 disparar um alerta quando o login sshd estivesse lá, mas não conseguisse criar nada.

Entradas apreciadas

A execução SSHem uma porta alternativa não conta mais como segurança. Ele apenas adiciona um pouco de obscuridade e uma etapa adicional de complexidade para seus usuários. Ele adiciona zero obstáculo para as pessoas que desejam interromper sua rede, que estão usando scanners de portas automatizados e não se importam com qual porta está sendo executada.

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

Crie dois grupos luserse rusers. Adicione os usuários móveis remotos ao rusersgrupo. Use o módulo PAM pam_succeed_if.so para permitir o acesso a esses usuários. Adicione linhas à sua configuração do 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 sintaxe um pouco diferente, como group = lusers.

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

Uma etapa adicional para os usuários remotos é forçar o uso de ssh_keys com senhas. Portanto, 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, poderá garantir que a chave tenha uma senha associada. Assim, limitando o acesso a locais que realmente possuem a chave SSH e a senha. E limitando possíveis vetores de ataque se a senha de um usuário for confirmada.

Em sshd_config:

altere 2 configurações:

ChallengeResponseAuthentication yes

e

PasswordAuthentication yes

para:

ChallengeResponseAuthentication no

e

PasswordAuthentication no

Portanto, o padrão é agora permitir apenas a autenticação de chave. Em seguida, para usuários locais, você pode usar a matchconfiguração 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 um benefício adicional, você só precisa gerenciar uma única sshd_confige executar o ssh em uma única porta, o que facilita seu próprio gerenciamento.

editar 21/01/2017 - Limitando o uso de authorized_keysarquivos.

Se você deseja garantir que os usuários não possam gerar apenas uma chave ssh e usá-la com um authorized_keysarquivo para efetuar login, você pode controlar que, definindo um local específico para o sshd, procure 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ê implementou.

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

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

O acima assume que o permitido usuários remotos são nomeados mobileuser1e mobileuser2, e que sua rede confiável é 10.0.0.0 com a máscara de sub-rede 255.0.0.0.

Isso permite que os dois usuários móveis efetuem login de qualquer lugar e que todos efetuem login na rede confiável. Qualquer usuário que não corresponda a nenhum desses padrões (como o foologin do usuário remoto) terá acesso negado.

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

Porta

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 log ssh alternativo para um arquivo diferente e, por exemplo, siga o que está escrito nesse arquivo para observar tentativas aberrantes de login.