Como restaurar o acesso remoto a um sistema RHEL a partir de permissões expandidas configuradas em todo o sistema de arquivos? [duplicado]

Question

Causa do problema

Eu pretendia adicionar permissão de gravação em grupo em arquivos ocultos como '.hgignore' com o seguinte:

# pwd
/opt
# sudo chmod -R g+w .*

O problema é que '..' correspondeu a esse padrão e agora todo o sistema de arquivos RHEL tem g + w definido. Os problemas imediatos são os seguintes:

• / etc / sudoers precisa ser configurado para 440, não para 460, então agora os usuários não podem usar o sudo.
• Algum mecanismo semelhante ao acima não permite acesso ssh. (Os clientes ssh remotos recebem a mensagem "ssh_exchange_identification: erro de conexão fechada pelo host remoto")

Pergunta

Para recuperar a capacidade de fazer login remotamente, alguém com acesso físico ao servidor precisa ser instruído sobre como consertar o sistema.

A pergunta agora é: quais arquivos e diretórios importantes precisam ter sua permissão revertida para restaurar a funcionalidade ssh e sudo ?

Nota sobre "fechado como duplicado"

A pergunta Por que o "chmod -R 777 /" é destrutivo? fornece explicações detalhadas sobre o efeito que as permissões de expansão recursiva podem ter. Esta questão destina-se a responder à questão de como recuperar o acesso remoto via ssh para que uma restauração e reparos mais extensos possam ser realizados.

    

Answer 1

Para arquivos que fazem parte de um pacote, você pode descobrir o que foi arruinado fazendo

rpm --verify "packagename"

em que packagename é um pacote individual ou você pode percorrer a saída de "rpm -qa"

Então você deve poder usar o rpm para corrigi-los com algo como

rpm --setperm "packagename"

    

Answer 2

O problema com o ssh não está mais limitado a apenas sob / etc e também tem a ver com a pasta .ssh do usuário com o qual você está tentando se conectar e com permissões incorretas. Geralmente, a pasta .ssh para um usuário deve ser 700, as chaves privadas devem ser 600 e tudo o mais pode ser 644.

A pasta / etc / ssh deve ser 755, sob / etc / ssh as chaves privadas devem ser 600, e todo o resto deve ser 644.

Howto recover a server from bad permissions in /etc?

Possivelmente, um dos métodos mais fáceis pode ser restaurar a partir do backup. Você faz backups e testou corretamente os procedimentos de restauração? :)

Se você não tiver um backup que possa ser usado para fazer uma restauração, talvez seja necessário configurar um sistema limpo que seja idêntico em uma VM e, em seguida, corrigir as permissões no host com base em seu servidor comparando as duas .

    

Answer 3

Se você tiver um bom servidor conhecido, executar algo como o seguinte no bom servidor pode ajudá-lo a restaurá-lo. (Assume a capacidade de globalização recursiva (zsh), poderia usar find com -exec / xargs):

for i in /etc/**/*; do
    perm=$(stat "$i" -c "%a")
    ssh root@badServerHostName "chmod $perm $i"
done

Pode haver um par de sub-diretórios para excluir outros que podem adicionar ... O Rsync seria melhor se ele pudesse fazer somente permissões, mas eu não acho que possa.

    

Answer 4

Se você tiver um backup e tiver LVM e espaço suficiente, poderá fazer o seguinte:

1.Restore o backup para um novo lv temporário (monte-o em / oldperm)
2. faça algo como o seguinte pseudocódigo:

foreach oldfile in /oldperm/* {  
  newf = strip "/oldperm" from oldfile  
  chmod --reference=oldfile newf  
}

Você pode restaurar parcialmente, como tudo em / etc, caso tenha problemas de espaço. Esse truque se baseia na sinalização chmod - referência que usa como modelo outro arquivo e faz com que o argumento seja compatível com a permissão.

Desta forma, você só restaura os perms antigos sem alterar o conteúdo dos arquivos.