Gosto da seguinte configuração para gerenciar o acesso SSH, usado no trabalho para gerenciar um grupo de usuários em uma pequena frota de servidores. Segurança e facilidade de gerenciamento estão no topo da lista de minhas prioridades.
Seus principais recursos são o gerenciamento fácil dos direitos SSH por meio da associação ao grupo Unix, com permissões bem definidas e segurança por padrão.
Configurando
Instale o software (opcional, mas útil):
yum install members # or apt install members
Adicione grupos:
addgroup --system allowssh
addgroup --system sftponly
Em /etc/ssh/sshd_config, verifique se as configurações a seguir são No:
PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no
E no final de /etc/ssh/sshd_config, adicione estas duas estrofes:
Match Group allowssh
PubkeyAuthentication yes
Match Group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
(não esqueça de reiniciar o SSH depois de editar o arquivo)
Explicação
Então, o que tudo isso faz?
- Desativa sempre logins raiz, como uma medida de segurança extra.
- Desativa sempre logins baseados em senha (senhas fracas são um grande risco para servidores executando o sshd).
- Permite apenas o login (pubkey) para usuários do
allowsshgrupo.
- Os usuários do
sftponlygrupo não podem obter um shell sobre SSH, apenas SFTP.
O gerenciamento de quem tem acesso é feito simplesmente gerenciando a associação ao grupo (essas alterações entram em vigor imediatamente, não é necessário reiniciar o SSH):
# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#
Observe que os usuários do sftp precisam ser membros de ambos sftponly(para garantir que não recebam um shell) e de allowssh(para permitir o login em primeiro lugar).
Outras informações
Observe que essa configuração não permite logins de senhas ; todas as contas precisam usar autenticação de chave pública. Esta é provavelmente a maior vitória em segurança que você pode obter com o SSH, então eu argumento que vale a pena o esforço, mesmo que você tenha que começar agora.
Se você realmente não quer isso, adicione também PasswordAuthentication yesà Match Group allowsshestrofe. Isso permitirá autenticação de pubkey e senha para os allowsshusuários.
Essa configuração limita qualquer sftponlyusuário ao diretório inicial. Se você não quiser isso, remova a ChrootDirectory %hdiretiva.
Se você não quer que o chrooting ao trabalho, é importante que o diretório home do usuário (e qualquer diretório acima dela) é de propriedade root:roote não gravável por grupo / outros. Não há problema em subdiretórios do diretório inicial serem de propriedade do usuário e / ou graváveis.
Sim, o diretório inicial do usuário deve pertencer à raiz e ser gravável para o usuário. Infelizmente, existem boas razões para essa limitação. Dependendo da sua situação, ChrootDirectory /homepode ser uma boa alternativa.
Definir o shell dos sftponlyusuários como /sbin/nologinnão é necessário nem prejudicial para esta solução, porque o SSH ForceCommand internal-sftpsubstitui o shell do usuário.
O uso /sbin/nologinpode ser útil para impedir o logon de outras maneiras (console físico, samba etc.).
Essa configuração não permite rootlogins diretos pelo SSH; isso forma uma camada extra de segurança. Se você realmente não precisa logins raiz diretos, alterar a PermitRootLogindirectiva. Considere configurá-lo para forced-commands-only, prohibit-passworde (como último recurso) yes.
Para obter pontos de bônus, verifique quem pode sutorcer; adicionar um grupo sistema chamado wheel, e adicionar / ativar auth required pam_wheel.sono /etc/pam.d/su.