Como evito que os usuários mexam em sua própria pasta .ssh?

A resposta curta é que você não pode.

O SSH é muito exigente quanto às permissões e não brinca com arquivos que não lhe agradam. Além disso, os usuários ssh_configsão analisados ​​antes da configuração de todo o sistema.

Dito isto, pode ser possível colocar os arquivos em outro lugar e montar o diretório como um sistema de arquivos somente leitura $HOME/.sshpara cada usuário. (É possível - mas não sei como o ssh e as ferramentas associadas tratariam isso).

Alguns deles já modificaram recursivamente 777-chmoded toda a sua própria pasta pessoal

Então você tem problemas muito maiores de SEGURANÇA e treinamento.

É difícil proteger os usuários de sua própria ignorância e incompetência.

Mas dependendo de quanto você precisa permitir que seus usuários gerenciem a si mesmos e quanto você gerencia para eles: você pode configurar o sshd para procurar chaves em um local alternativo fora de seu diretório inicial e em outro lugar que não seja ~/.ssh/authorized_keys.

Comando de Chaves Autorizadas

Uma solução relativamente complexa é a diretiva que, em vez de depender de arquivos autorizados_keys, especifica um programa a ser usado para pesquisar as chaves públicas do usuário, por exemplo:/etc/ssh/sshd_config AuthorizedKeysCommand

• um diretório LDAP

• um banco de dados

• um serviço web (trivial)

• ou quando seus nomes de usuário são idênticos aos nomes de usuário do Github, você pode permitir que os usuários se autentiquem com os pares de chaves que eles carregaram lá:

  AuthorizedKeysCommand /usr/bin/curl https://github.com/%u.keys
  

Conforme mencionado nesta resposta ; você precisará criar uma política SELinux adequada para AuthorizedKeysCommand, pois ela será bloqueada pelas políticas padrão.

Adoro essa abordagem, pois ela pode resolver muitos problemas relacionados ao gerenciamento de chaves autorizadas: adiciona gerenciamento centralizado, elimina o problema do ovo e da galinha de obter chaves autorizadas para servidores quando você deseja desabilitar a autenticação de senha no ssh e muito mais.
Ele aproveita o fato de que as chaves públicas não são particularmente sensíveis (ao contrário das chaves privadas associadas), portanto centralizar seu gerenciamento não adiciona risco IMHO e provavelmente até melhora seus recursos de controle e relatórios.

Arquivo de chaves autorizadas

Um pouco menos complexo é armazenar chaves em um diretório fora de seu diretório inicial. Por exemplo, use /etc/ssh/<username>(substituindo <username>pelo nome de usuário real). Este diretório deve ter 755 permissões e pertencer ao usuário. Mova o authorized_keysarquivo para ele. O arquivoauthorized_keys ainda deve ter permissões 644 e pertencer ao usuário.

Em /etc/ssh/sshd_configajustar a AuthorizedKeysFileconfiguração

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

E reinicie o daemon ssh

A melhor solução que consigo pensar é criar .sshe ser authorized_keysde propriedade do root.

.ssh/authorized_keys de propriedade da raiz

O SSH é exigente com permissões, mas não sem razão. Primeiro, requer que o próprio usuário tenha acesso de leitura authorized_keys(o que requer acesso de leitura a todos os diretórios pai). Em segundo lugar, ele nega acesso se qualquer usuário que não seja o próprio usuário ou root tiver acesso de gravação a /home, .sshou authorized_keys. Isso não permite o+we g+wpara um grupo que contém outros usuários.

Esta configuração funciona para mim, o usuário pode fazer login:

drwxr-xr-x 19 root root 4096 Sep 22 11:24 /
drwxr-xr-x  3 root root 4096 Sep 22 11:19 /home/
drwx------ 14 test test 4096 Sep 22 11:44 /home/test/
drwxr-x---  2 root test 4096 Sep 22 11:42 /home/test/.ssh/
-rw-r--r--  1 root test   98 Sep 22 11:36 /home/test/.ssh/authorized_keys

Como .sshe authorized_keyssão de propriedade do root, o usuário não pode alterar as permissões deles ou removê-los. Eles também não podem editar seu próprio authorized_keysarquivo.

Se quiser permitir que o usuário edite seus arquivos authorized_keys, você pode adicionar permissões de gravação em grupo. Isso requer que o testgrupo não tenha outros membros além testdele mesmo:

-rw-rw-r--  1 root test   99 Sep 22 12:04 /home/test/.ssh/authorized_keys

Com qualquer abordagem, o usuário não poderá mais criar seus próprios arquivos em .ssh, portanto, você também pode fornecer alguns arquivos extras para eles. Alguns que vêm à mente são: known_hosts, confige/ id_rsa{.pub,}ou outros tipos de chave.

Alternativa: chattr

Alguns sistemas de arquivos Linux suportam atributos de arquivo , notadamente um sinalizador imutável . Arquivos/diretórios com o sinalizador imutável definido não podem ser excluídos, modificados ou ter suas permissões alteradas. Somente o root pode definir/desmarcar este sinalizador.

Este comando resolveria o problema, mesmo com a propriedade/permissões padrão:

# chattr +i ~test/.ssh/{authorized_keys,}

Agora .sshe authorized_keysnão pode ser modificado de forma alguma, nem mesmo por root. Se o root precisar atualizar esses arquivos, você precisará deles chattr -iprimeiro. Use lsattrpara verificar atributos.

Essa abordagem é mais simples, mas menos flexível. Também precisa de suporte ao sistema de arquivos; Acredito que seja compatível com pelo menos ext2/3/4, XFS e btrfs.

ACLs Posix?

Há também Posix ACLs (listas de controle de acesso), que permitem um controle um pouco mais refinado. Não estou muito familiarizado com eles e não tenho certeza se eles ajudam aqui.

Modos Estritos

Nota: altamente desencorajado, mas previsto para ser completo.

O servidor OpenSSH possui uma diretiva de configuração chamada StrictModes, que determina o quão exigente é o SSH com permissões:

Especifica se o sshd deve verificar os modos de arquivo e a propriedade dos arquivos e do diretório inicial do usuário antes de aceitar o login. Isso normalmente é desejável porque os novatos às vezes deixam acidentalmente seus diretórios ou arquivos graváveis. O padrão é yes.

Se você desabilitar essa opção, terá mais liberdade para configurar propriedade e permissões. No entanto, o SSH é rigoroso por padrão por boas razões. Um usuário 777-chmodding em seus arquivos SSH é um risco à segurança.

Execute um cron job para corrigir permissões todas as noites.

Excluir arquivos é um pouco mais difícil. Você também pode restaurar arquivos ausentes do backup do cron. Mas parece que você pode entrar em casos estranhos com isso ... pode precisar de mais inteligência do que um script pode fornecer. Eu começaria aos poucos e adicionaria recursos com cautela a uma função de restauração.