Con respecto a la tercera estrategia sugerida, aparte de useradd -o -u userXXXleer detenidamente las opciones recomendadas por @jlliagre, no estoy familiarizado con ejecutar múltiples usuarios como el mismo uid. (Por lo tanto, si continúa con eso, me interesaría si pudiera actualizar la publicación con cualquier problema (o éxito) que surja ...)
Supongo que mi primera observación con respecto a la primera opción "La clave pública SSH de todos se coloca en ~ root / .ssh / Authorizedkeys2", es que a menos que nunca vaya a trabajar en ningún otro sistema;
- entonces al menos parte del tiempo , tendrás que trabajar con cuentas de usuario y
sudo
La segunda observación sería que si trabaja en sistemas que aspiran al cumplimiento de HIPAA, PCI-DSS o cosas como CAPP y EAL, entonces tendrá que solucionar los problemas de sudo porque;
- Es un estándar de la industria para proporcionar cuentas de usuario individuales no root, que se pueden auditar, deshabilitar, caducar, etc., generalmente utilizando alguna base de datos de usuarios centralizada.
Asi que; Usando cuentas personalizadas y sudo
Es desafortunado que, como administrador de sistemas, casi todo lo que necesite hacer en una máquina remota requiera algunos permisos elevados, sin embargo, es molesto que la mayoría de las herramientas y utilidades basadas en SSH se rompan mientras está en sudo
Por lo tanto, puedo transmitir algunos trucos que utilizo para solucionar las molestias sudoque mencionas. El primer problema es que si el inicio de sesión raíz está bloqueado usando PermitRootLogin=noo si no tiene la raíz usando la clave ssh, entonces los archivos SCP son algo así como un PITA.
Problema 1 : desea scp archivos desde el lado remoto, pero requieren acceso de root, sin embargo, no puede iniciar sesión en el cuadro remoto como root directamente.
Solución aburrida : copie los archivos en el directorio de inicio, chown y scp down.
ssh userXXX@remotesystem, sudo su -etc., cp /etc/somefilesa /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesuse scp para recuperar archivos de forma remota.
Muy aburrido de hecho.
Solución menos aburrida : sftp admite el -s sftp_serverindicador, por lo tanto, puede hacer algo como lo siguiente (si ha configurado sudo sin contraseña /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(también puedes usar este truco con sshfs, pero no estoy seguro de que sea recomendable ... ;-)
Si no tiene derechos de sudo sin contraseña, o por alguna razón configurada de que el método anterior no funciona, puedo sugerir un método de transferencia de archivos menos aburrido, para acceder a los archivos raíz remotos.
Método Ninja de reenvío de puertos :
Inicie sesión en el host remoto, pero especifique que el puerto remoto 3022 (puede ser cualquier cosa libre y no reservado para administradores, es decir,> 1024) se debe reenviar al puerto 22 en el 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
------------------------------------------------------------------------
Echar raíces en la moda normal ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Ahora puede scp los archivos en la otra dirección evitando el paso aburrido aburrido de hacer una copia intermedia de los archivos;
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Problema 2: reenvío de agente SSH : si carga el perfil raíz, por ejemplo, al especificar un shell de inicio de sesión, las variables de entorno necesarias para el reenvío de agente SSH, como por ejemplo, SSH_AUTH_SOCKse restablecen, por lo tanto, el reenvío de agente SSH está "roto" sudo su -.
Respuesta a medias :
Todo lo que cargue correctamente un shell raíz restablecerá el entorno correctamente, sin embargo, hay una pequeña solución que puede usar cuando necesita AMBOS permisos de root Y la capacidad de usar el Agente SSH, AL MISMO TIEMPO
Esto logra un tipo de perfil de quimera, que realmente no debería usarse, porque es un truco desagradable , pero es útil cuando necesita archivos SCP desde el host remoto como root, a algún otro host remoto.
De todos modos, puede habilitar que su usuario pueda preservar sus variables ENV, configurando lo siguiente en sudoers;
Defaults:userXXX !env_reset
esto le permite crear entornos de inicio de sesión híbridos desagradables como este;
iniciar sesión de forma 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
crear un shell bash, que se ejecute /root/.profiley /root/.bashrc. pero conservaSSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Entonces este shell tiene permisos de root y root $PATH(pero un directorio de inicio descifrado ...)
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
Pero puede usar esa invocación para hacer cosas que requieren sudo root remoto, pero también el acceso del agente SSH como tal;
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#
-obandera en lauseraddpágina del manual. Esta bandera está ahí para permitir que múltiples usuarios compartan el mismo uid.