Se eu mudar a senha do root em um servidor linux, alguém ainda poderá acessar o root se eles criaram um SSH authorized_key para usuário root?

Question

Eu nem tenho certeza se perguntei direito. Sempre que alguém menciona alterar a senha de root, eles mencionam alterar /etc/passwd , ou apenas usando o comando passwd , mas eu nunca ouvi falar de ter que alterá-lo em um arquivo authorized_keys também. Onde posso encontrar isso e como posso excluir com segurança uma entrada ou alterar isso para raiz sem causar estragos? Obrigado!

    

Answer 1

Sim. Você precisará excluir a chave SSH pública do usuário para remover completamente o acesso. Se você está simplesmente tentando remover o acesso de um usuário ao root, é um pouco complicado. Espero que você esteja usando chaves privadas separadas, porque senão você terá que recriar o arquivo e redistribuir as chaves públicas para os usuários autorizados.

Para remover a entrada, você precisa editar o arquivo authorized_keys . Se este for seu usuário root em uma caixa Linux, provavelmente o arquivo pode ser encontrado em /root/.ssh/authorized_keys . Você precisará remover a linha que contém a chave pública do usuário que você está removendo. Infelizmente, não há maneira fácil de saber qual linha é essa sem uma cópia da chave pública do usuário.

    

Answer 2

Sim; é considerado uma prática ruim permitir que as pessoas usem o ssh como "root" exatamente por esse motivo. Suas caixas provavelmente devem ter o ssh desativado do root e usar algo como "sudo" para fornecer controles de acesso sobre quem pode fazer o que é root, assim você não precisará fornecer a senha de root ou algo equivalente.

As contas dos que deixam as pessoas podem simplesmente ser desabilitadas e você pode garantir que elas não podem voltar (a não ser, é claro, elas deixaram algumas portas nos fundos, algo que você não pode fazer nada de qualquer maneira).

Usamos um diretório ldap para armazenar usuários, grupos e chaves ssh e, em seguida, restringimos o acesso "sudo" por grupo.

    

Answer 3

Se alguém tiver raiz, é muito difícil, talvez impossível, ter certeza de que não conseguirá recuperá-la, a menos que você reinstale e restaure a partir de um backup feito antes que eles tivessem acesso. Pontos a observar: primeiro um truque antigo: qualquer usuário extra em /etc/passwd com UID 0. Por exemplo:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
..etc...
something-innocuous:0:42:foo:/:/bin/sh
..etc..

Esse usuário extra teria uma senha separada e seria efetivamente root assim que fizesse login.

Execute visudo se você tiver sudo instalado e verifique se há algo incomum lá.

Você deve verificar /etc/pam.conf e todo /etc/pam.d (possivelmente em outro lugar também?) para garantir que nada esteja configurando o PAM para conceder login sem senha para root de um IP particular ou similar.

Você deve verificar se há processos extras sendo executados como raiz, que podem oferecer um shell raiz a um usuário remoto ou local específico; o executável desse processo não precisa mais existir no disco ou não precisa ser o que era quando o processo foi iniciado.

Finalmente, se você ainda não acha que é impossível: pesquise quaisquer pontos de montagem cujas opções de montagem não contenham nosuid para binários setuid / setgid (usando algo como find -perm /6000 ) ou binários que o root possa executar, pode ter sido modificado. Quais podem ter sido modificados / adicionados recentemente? Qualquer um deles. Os timestamps são triviais para mudar.

Um rootkit pode ter feito qualquer combinação dos itens acima e pode ter corrigido o kernel (talvez também na memória, sem uma reinicialização) para impedir sua capacidade de detectá-lo (removendo coisas do ps / netstat, etc.)

Boa sorte. : -)

    

Answer 4

Se você usa chaves SSH, convém considerar a desativação completa de uma senha.

O SSH está perto de ser solto sem senhas, mas esses dois são como um "ou", então se você pode hackar também, você é hackeado.

    

Answer 5

Você pode desativar logins de root via ssh, definindo PermitRootLogin no em seu arquivo sshd_config. Se você tiver servidores trocando dados ou executando remotamente comandos como root (por exemplo, fazer backup de alguns sistemas), provavelmente não desejará fazer isso. Se este for o caso, a resposta de Kyle Cronin é o caminho a seguir.

    

Answer 6

Vale a pena pensar muito sobre usar as chaves autorizadas do ssh para o root.

Digamos que eu possa ser root no sistema ZZ e adicionar minha chave pública ao authorized_key do root. Agora, minha chave privada é muito mais valiosa, porque agora ela não apenas permite que alguém invada todas as minhas contas, mas também permite o root no ZZ. Além disso, é claro, qualquer sistema que faça root no ZZ também seja root em si mesmo.

Observe que, se eu colocar minha chave privada em um sistema em que outras pessoas possam fazer root, esses usuários também poderão obter root no ZZ, já que podem obter minha chave privada de forma trivial.

etc

etc

etc

É um relaxamento muito perigoso da segurança. As pessoas tendem a ser um pouco livres sobre onde colocam sua chave privada, pois isso torna o ssh muito mais fácil.

Concordo com o ssh root junto com o sudo, mas, se você fizer isso, talvez queira adicionar usuários especiais que não tenham dependência de rede NIS / LDAP / NFS / etc para que você ainda possa efetuar login quando houver rede fubar. Normalmente, o root pode efetuar login quando outros não conseguem, já que o root tende a ter menos desses requisitos externos.