Em nossa equipe, temos três administradores de sistemas Linux experientes tendo que administrar algumas dúzias de servidores Debian. Anteriormente, todos nós trabalhamos como root usando autenticação de chave pública SSH. Mas tivemos uma discussão sobre qual é a melhor prática para esse cenário e não conseguimos concordar com nada.
Dessa forma, faríamos login com contas personalizadas usando chaves públicas SSH e usaríamos sudo para realizar tarefas únicas com permissões root . Além disso, poderíamos nos dar o grupo "adm" que nos permite visualizar arquivos de log.
Esta é uma proposta muito original de um dos administradores de sistema. Ele sugere criar três usuários em / etc / passwd, todos tendo UID 0, mas diferentes nomes de login. Ele alega que isso não é realmente proibido e permite que todos sejam UID 0, mas ainda assim possam auditar.
O que você sugeriria?
A segunda opção é a melhor IMHO. Contas pessoais, acesso sudo. Desabilite o acesso root via SSH completamente. Temos algumas centenas de servidores e meia dúzia de administradores de sistema, é assim que fazemos.
Como o encaminhamento de agentes é interrompido exatamente?
Além disso, se for um incômodo usando sudo na frente de cada tarefa, você pode invocar um shell sudo com sudo -s ou alternar para um shell raiz com sudo su -
Com relação à terceira estratégia sugerida, além da leitura das opções useradd -o -u userXXX como recomendado por @jlliagre, não estou familiarizado com a execução de vários usuários como o mesmo uid. (portanto, se você prosseguir com isso, eu estaria interessado se você pudesse atualizar o post com quaisquer problemas (ou sucessos) que surgissem ...)
Acho que minha primeira observação sobre a primeira opção "A chave pública SSH de todo mundo é colocada em ~ root / .ssh / authorized_keys2", é que a menos que você absolutamente nunca vá trabalhar em nenhum outro sistema;
sudo
Então; Uso de contas personalizadas e sudo
É lamentável que, como um administrador de sistemas, quase tudo que você precisa fazer em uma máquina remota exija algumas permissões elevadas, mas é irritante que a maioria das ferramentas e utilitários baseados em SSH sejam eliminados enquanto você está em sudo
Por isso, posso passar alguns truques que utilizo para resolver os problemas de sudo que mencionou. O primeiro problema é que, se o login root for bloqueado usando PermitRootLogin=no ou se você não tiver a raiz usando a chave ssh, isso fará com que os arquivos SCP sejam um pouco PITA.
Problema 1 : Você deseja scp arquivos do lado remoto, mas eles exigem acesso root, no entanto, você não pode acessar a caixa remota como root diretamente.
Solução de perfuração : copie os arquivos para o diretório home, chown e scp para baixo.
ssh userXXX@remotesystem , sudo su - etc, cp /etc/somefiles a /home/userXXX/somefiles , chown -R userXXX /home/userXXX/somefiles , use o scp para recuperar arquivos remotos.
Muito chato mesmo.
Solução menos enfadonha : o sftp suporta o sinalizador -s sftp_server , portanto você pode fazer algo como o seguinte (se você configurou o sudo sem senha em /etc/sudoers );
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(você também pode usar este hack-around com o sshfs, mas não tenho certeza se é recomendado ...; -)
Se você não tem direitos sudo sem senha, ou por algum motivo configurado que o método acima está quebrado, posso sugerir um método de transferência de arquivos mais chato, para acessar arquivos raiz remotos.
Método Ninja de Encaminhamento de Portas :
Faça login no host remoto, mas especifique que a porta remota 3022 (pode ser qualquer coisa livre e não reservada para administradores, por exemplo, > 1024) deve ser encaminhada de volta para a porta 22 no lado local.
[localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
Obtenha root da maneira normal ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Agora você pode scp os arquivos na outra direção, evitando o chato passo chato de fazer uma cópia intermediária dos arquivos;
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Problema 2: encaminhamento de agentes SSH : se você carregar o perfil raiz, por exemplo, especificando um shell de login, as variáveis de ambiente necessárias para o encaminhamento do agente SSH, como SSH_AUTH_SOCK , são reconfiguradas, portanto, o encaminhamento do agente SSH é "quebrado" em sudo su - .
Resposta parcialmente preparada :
Qualquer coisa que carregue corretamente um shell de root, irá restabelecer corretamente o ambiente, no entanto, há um pequeno trabalho que você pode usar quando precisar de ambas as permissões de root E a habilidade de usar o Agente SSH, AO MESMO TEMPO
Isso alcança um tipo de perfil quimera, que realmente não deve ser usado, porque é um hack desagradável , mas é útil quando você precisa de arquivos SCP do host remoto como root, para alguns outro host remoto.
De qualquer forma, você pode permitir que seu usuário possa preservar suas variáveis ENV, definindo o seguinte em sudoers;
Defaults:userXXX !env_reset
isso permite que você crie ambientes de login híbridos desagradáveis como assim;
faça o login como normal;
[localuser@localmachine ~]$ ssh userXXX@remotehost
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971
crie um shell bash que execute /root/.profile e /root/.bashrc . mas preserva SSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Portanto, este shell tem permissões de root e root $PATH (mas um diretório inicial borked ...)
bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin
Mas você pode usar essa invocação para fazer coisas que exigem raiz sudo remota, mas também o acesso do agente SSH assim;
bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys 100% 126 0.1KB/s 00:00
bash-3.2#
A terceira opção parece ideal - mas você já experimentou para ver o que está acontecendo? Enquanto você pode ver os nomes de usuários adicionais na etapa de autenticação, qualquer pesquisa inversa retornará o mesmo valor.
Permitir acesso root direto ao ssh é uma má ideia, mesmo que suas máquinas não estejam conectadas à internet / usem senhas strongs.
Normalmente, uso 'su' em vez de sudo para acesso root.
Eu uso (1), mas aconteceu de eu digitar
rm -rf / tmp *
em um dia malfadado. Posso ver que é ruim o suficiente se você tiver mais de um punhado de administradores.
(2) É provavelmente mais engenharia - e você pode se tornar root de pleno direito através do sudo su -. Acidentes ainda são possíveis.
(3) Eu não tocaria em um poste de barcaça. Eu usei isso no Suns, para ter uma conta root não barebone-sh (se bem me lembro), mas nunca foi robusta - além disso, duvido que seja muito auditável.
Definitivamente responda 2.
Significa que você está permitindo o acesso SSH como root . Se esta máquina está de alguma forma voltada para o público, esta é apenas uma idéia terrível; Quando eu rodava o SSH na porta 22, meu VPS tinha várias tentativas por hora para autenticar como root. Eu tinha um IDS básico configurado para registrar e proibir IPs que fizessem várias tentativas com falha, mas elas continuavam chegando. Felizmente, eu tinha desativado o acesso SSH como usuário root assim que eu tinha minha própria conta e sudo configurados. Além disso, você praticamente não tem uma trilha de auditoria fazendo isso.
Fornece acesso root quando e como é necessário. Sim, você mal tem privilégios como usuário padrão, mas isso é exatamente o que você quer; Se uma conta for comprometida, você quer que ela seja limitada em suas habilidades. Você deseja que qualquer acesso de superusuário exija uma reinserção de senha. Além disso, o acesso sudo pode ser controlado por meio de grupos de usuários e restrito a comandos específicos, se você quiser, dando a você mais controle sobre quem tem acesso a quê. Além disso, os comandos executados como sudo podem ser registrados, portanto, fornece uma trilha de auditoria muito melhor se as coisas derem errado. Ah, e não basta executar "sudo su -" assim que você fizer login. Essa é uma prática terrível e terrível.
A ideia do seu sysadmin é ruim. E ele deveria se sentir mal. Não, as máquinas * nix provavelmente não vão impedi-lo de fazer isso, mas tanto o seu sistema de arquivos quanto praticamente todos os aplicativos esperam que cada usuário tenha um UID exclusivo. Se você começar a ir por esse caminho, posso garantir que você vai ter problemas. Talvez não imediatamente, mas eventualmente. Por exemplo, apesar de exibir bons nomes amigáveis, arquivos e diretórios usam números UID para designar seus proprietários; Se você se deparar com um programa que tem um problema com UIDs duplicados, você não pode simplesmente alterar um UID em seu arquivo passwd mais tarde, sem ter que fazer uma limpeza séria do sistema de arquivos manual.
sudo é o caminho a seguir. Isso pode causar problemas adicionais com a execução de comandos como root, mas fornece uma caixa mais segura, tanto em termos de acesso quanto de auditoria.
Definida opção 2, mas use grupos para dar a cada usuário o máximo de controle possível sem precisar usar o sudo. sudo na frente de cada comando perde metade do benefício porque você está sempre na zona de perigo. Se você fizer os diretórios relevantes graváveis pelos sysadmins sem sudo, você retorna o sudo à exceção que faz com que todos se sintam mais seguros.
Nos velhos tempos, o sudo não existia. Como consequência, ter vários usuários do UID 0 era a única alternativa disponível. Mas ainda não é tão bom, especialmente com o log baseado no UID para obter o nome de usuário.
Hoje em dia, o sudo é a única solução apropriada. Esqueça qualquer outra coisa.
É documentado permissível por fato. Unidades BSD tiveram sua conta de usuário por um longo tempo, e usuários bashroot tendem a ser aceitos em sistemas onde o csh é padrão (má prática aceita;)
Talvez eu seja estranho, mas o método (3) é o que surgiu em minha mente também. Prós: você teria todos os nomes de usuários em logs e saberia quem fez o quê como root. Contras: cada um deles seria raiz o tempo todo, então os erros podem ser catastróficos.
Gostaria de perguntar por que você precisa que todos os administradores tenham acesso root. Todos os três métodos propostos têm uma desvantagem distinta: quando um administrador executa um sudo bash -l ou sudo su - , você perde sua capacidade de acompanhar quem faz o quê e, depois disso, um erro pode ser catastrófico. Além disso, em caso de possível mau comportamento, isso pode até ser muito pior.
Em vez disso, você pode querer pensar em outra maneira:
Dessa forma, o martin poderia manipular com segurança o postfix e, em caso de erro ou mau comportamento, você perderia apenas o sistema de pós-inserção, não o servidor inteiro.
A mesma lógica pode ser aplicada a qualquer outro subsistema, como apache, mysql, etc.
Claro, isso é puramente teórico neste momento e pode ser difícil de configurar. Parece uma maneira melhor de ir embora. Pelo menos para mim. Se alguém tentar isso, por favor, deixe-me saber como foi.