Eu não sou um administrador de sistemas e tento criar um servidor da Web mais ou menos seguro (baseado em LAMP CentOS 7 ).
Eu li vários tutoriais sobre como configurar um droplet inicial do CentOS 7 e fazer tudo correr bem.
No entanto, estou lutando para entender alguns conceitos básicos que leio nos artigos que leio e preciso de algumas sugestões de pessoas mais qualificadas, simplesmente porque não tenho certeza sobre os efeitos colaterais.
Sua opinião é muito apreciada.
Cenário:
Estou usando cloud-init (User Data) no Digital Ocean para criar & provisionar uma nova gota.
Até onde eu entendi, o cloud-init roda como system / root, criando as configurações abaixo, específicas para ssh_config para root:
- para criar um novo usuário (vamos chamá-lo de administrador para este cenário) na linha
com uma chave ssh para esse usuário (ssh-authorized-keys) a
- adicionando esse usuário aos grupos roda e defina sudo: ['ALL = (ALL) NOPASSWD: ALL']
- desabilite o login root em / etc / ssh / sshd_config
- Administrador do AllowUsers em / etc / ssh / sshd_config
- defina PasswordAuthentication no em / etc / ssh / sshd_config
- define o PubkeyAuthentication yes & RSAAuthentication sim em / etc / ssh / sshd_config
- configurando o firewalld e executando algumas outras tarefas
Perguntas:
-
Após conectar meu droplet através do ssh como user admin, o sshd_config relacionado está vazio. Suponho que isso se deva ao fato de o cloud-init ser executado como system / root quando o droplet é criado e o cloudconfig é executado.
1.1 Preciso definir as mesmas configurações aqui como na criação de droplets para o usuário root?
1.2 Se sim, qual é o sentido de vários arquivos ssh_config?
-
Olhando para o arquivo de log cloud-init, descobri que um par de chaves rss pública / privada para raiz foi criado.
A senha relacionada é enviada para mim porque decidi não fornecer uma chave ssh inicial para o usuário raiz (apenas para fins de teste).
No entanto, a execução de ls -a em / etc/ssh do administrador do usuário recém-criado é exibida:
. moduli sshd_config ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub
.. ssh_config ssh_host_dsa_key ssh_host_ecdsa_key ssh_host_rsa_key
Olhando para ssh_host_rsa_key, por exemplo, ele contém a mesma chave ssh que foi criada para o usuário root.
2.1 Por que e com que propósito o usuário recém-criado que eu chamei de admin (não root) possui as mesmas chaves que root em sua pasta ssh?
2.2 É porque eu adicionei ele à roda de grupos e ao sudo: ['ALL = (ALL) NOPASSWD: ALL ‘]? Isso é recomendado?
2.3 Qual é a sensação de não permitir root ao login remoto através de ssh se outra conta de usuário pode ser comprometida e também possui todas as chaves necessárias para tornar um hacker uma pessoa de muita sorte? O propósito é apenas ter um usuário cujo nome é mais difícil de adivinhar?
-
Eu entendi que algumas ações ainda exigem privilégios sudo / root. Se logado como admin eu posso mudar para root usando su root.
3.1 Como eu desabilitei o login root em / etc / ssh / sshd_config (isto é, somente para ssh, certo?) mas o novo usuário criado (admin) tem os mesmos direitos e pode facilmente mudar para Estou me perguntando o que pode ser feito para proteger melhor essa senha ou se há algo como Two Factor Auth que adiciona um nível de segurança?
3.2. Por outro lado, não entendo como esse pode ser um nível melhor de segurança se um hacker que obteve o controle da conta de administrador pode ler facilmente as chaves ssh para root ( ver o tópico anterior acima) e ignorar qualquer camada de segurança?
Em suma:
Eu gostei muito do que eu estava lendo, mas olhando para o filesyste, em específico, depois de encontrar as chaves ssh (privado e público) na pasta ssh dos usuários que eu criei usando cloud-init, estou um pouco preocupado que eu entendi mal alguma coisa .
A propósito: este é o meu script cloud-init:
#cloud-config
# log all cloud-init process output (info & errors) to a logfile
output: {all: ">> /var/log/cloud-init-output.log"}
# final_message written to log when cloud-init processes are finished
final_message: "System boot (via cloud-init) is COMPLETE, after $UPTIME seconds. Finished at $TIMESTAMP"
package_upgrade: true
users:
- name: admin
groups: wheel
sudo: ['ALL=(ALL) NOPASSWD:ALL']
shell: /bin/bash
ssh-authorized-keys:
- ssh-dss AAAABBBBBCCCCDDDD...
runcmd:
- sed -i -e 's/#Protocol 2/Protocol 2/g' /etc/ssh/sshd_config
- sed -i -e 's/#LoginGraceTime 2m/LoginGraceTime 2m/g' /etc/ssh/sshd_config
- sed -i -e 's/#PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config
- sed -i -e 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config
- sed -i -e 's/#RSAAuthentication yes/RSAAuthentication yes/g' /etc/ssh/sshd_config
- sed -i -e 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/g' /etc/ssh/sshd_config
- sed -i -e '$aAllowUsers admin' /etc/ssh/sshd_config
- service sshd restart
#firewall
- systemctl start firewalld
- firewall-cmd --permanent --add-service=ssh
- firewall-cmd --reload
- systemctl enable firewalld