Com relação à 3ª estratégia sugerida, além da leitura das useradd -o -u userXXXopções recomendadas por @jlliagre, não estou familiarizado com a execução de vários usuários com o mesmo uid. (portanto, se você continuar com isso, eu estaria interessado em atualizar a postagem com quaisquer problemas (ou sucessos) que surjam ...)
Acho que minha primeira observação sobre a primeira opção "A chave pública SSH de todos é colocada em ~ root / .ssh / allowed_keys2", é que, a menos que você nunca trabalhe em outros sistemas;
- pelo menos uma parte do tempo , você terá que trabalhar com contas de usuário e
sudo
A segunda observação seria que, se você trabalha em sistemas que aspiram a HIPAA, conformidade com PCI-DSS ou coisas como CAPP e EAL, terá que contornar as questões do sudo porque;
- É um padrão do setor fornecer contas de usuário individuais não raiz, que podem ser auditadas, desativadas, expiradas, etc., geralmente usando algum banco de dados centralizado do usuário.
Tão; Usando contas personalizadas e sudo
É lamentável que, como administrador de sistemas, quase tudo que você precise fazer em uma máquina remota exija algumas permissões elevadas, no entanto, é irritante que a maioria das ferramentas e utilitários baseados em SSH sejam bloqueados enquanto você estiver sudo
Por isso, posso passar alguns truques que uso para contornar os aborrecimentos sudomencionados. O primeiro problema é que, se o login root for bloqueado PermitRootLogin=noou se você não tiver a raiz usando a chave ssh, isso tornará os arquivos SCP uma espécie de PITA.
Problema 1 : Você deseja scp arquivos do lado remoto, mas eles exigem acesso root, no entanto, você não pode efetuar login diretamente na caixa remota como root.
Solução chata : copie os arquivos para o diretório inicial, o chown e o scp.
ssh userXXX@remotesystem, sudo su -etc, cp /etc/somefilespara /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesuse scp para recuperar arquivos do controle remoto.
Muito chato mesmo.
Solução menos chata : o sftp suporta o -s sftp_serversinalizador, portanto, você pode fazer algo como o seguinte (se você configurou o sudo sem senha /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(você também pode usar esse hack-around com sshfs, mas não tenho certeza se é recomendado ... ;-)
Se você não possui direitos sudo sem senha ou, por algum motivo configurado, o método acima está quebrado, posso sugerir mais um método de transferência de arquivos menos chato, para acessar arquivos raiz remotos.
Método Ninja de encaminhamento de porta :
Efetue login no host remoto, mas especifique que a porta remota 3022 (pode ser qualquer coisa livre e não reservada para administradores, ou seja,> 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
------------------------------------------------------------------------
Faça root da maneira normal ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Agora você pode scp os arquivos na outra direção, evitando a etapa chata 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 agente SSH : Se você carregar o perfil raiz, por exemplo, especificando um shell de logon, as variáveis de ambiente necessárias para o encaminhamento de agente SSH, como SSH_AUTH_SOCKsão redefinidas, portanto, o encaminhamento do agente SSH é "quebrado" sudo su -.
Resposta meio assada :
Qualquer coisa que carregue corretamente um shell raiz, redefinirá o ambiente corretamente, no entanto, há uma pequena solução alternativa que você pode usar quando precisar de ambas as permissões de root E a capacidade de usar o Agente SSH, AO MESMO TEMPO
Isso atinge um tipo de perfil de quimera, que realmente não deve ser usado, porque é um hack desagradável , mas é útil quando você precisa SCP arquivos do host remoto como root, para algum outro host remoto.
De qualquer forma, você pode permitir que seu usuário preserve 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 esse;
faça o login normalmente;
[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/.profilee /root/.bashrc. mas preservaSSH_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 com 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 chamada para fazer coisas que exijam raiz sudo remota, mas também o acesso ao 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#
-obandeira nauseraddpágina de manual. Este sinalizador existe para permitir que vários usuários compartilhem o mesmo uid.