Per quanto riguarda la terza strategia suggerita, oltre alla lettura del useradd -o -u userXXX opzioni come raccomandato da @jlliagre, non ho familiarità con l'esecuzione di più utenti come lo stesso uid. (quindi se vai avanti con questo, sarei interessato se potessi aggiornare il post con eventuali problemi (o successi) che si presentano ...)
Immagino che la mia prima osservazione riguardo alla prima opzione "La chiave pubblica SSH di tutti è messa in ~ root / .ssh / authorized_keys2", è che a meno che tu non abbia mai intenzione di lavorare su altri sistemi;
- poi almeno qualche volta , dovrai lavorare con gli account utente e
sudo
La seconda osservazione sarebbe che se si lavora su sistemi che aspirano a HIPAA, conformità PCI-DSS o cose come CAPP ed EAL, allora si dovrà aggirare i problemi di sudo perché;
- È uno standard industriale per fornire account utente individuali non root, che possono essere controllati, disabilitati, scaduti, ecc., In genere utilizzando un database utente centralizzato.
Così; Utilizzando account personalizzati e sudo
È un peccato che come amministratore di sistema, quasi tutto ciò che dovrai fare su una macchina remota richiederà alcune autorizzazioni elevate, tuttavia è fastidioso che la maggior parte degli strumenti e delle utilità basati su SSH siano bloccati mentre sei in sudo
Quindi posso passare alcuni trucchi che uso per aggirare i fastidi di sudocui parli. Il primo problema è che se l'accesso root è bloccato usandoPermitRootLogin=no o che non si ha il root usando la chiave ssh, i file SCP diventano qualcosa di PITA.
Problema 1 : si desidera scp i file dal lato remoto, ma richiedono l'accesso come root, tuttavia non è possibile accedere direttamente alla casella remota come root.
Soluzione noiosa : copia i file nella home directory, chown e scp down.
ssh userXXX@remotesystem, sudo su -ecc. cp /etc/somefilesa/home/userXXX/somefiles , chown -R userXXX /home/userXXX/somefiles, uso SCP per il recupero di file da remoto.
Davvero molto noioso.
Soluzione meno noiosa : sftp supporta il -s sftp_serverflag, quindi puoi fare qualcosa di simile al seguente (se hai configurato sudo senza password /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(puoi anche usare questo hack-around con sshfs, ma non sono sicuro che sia consigliato ... ;-)
Se non si dispone di diritti sudo senza password, o per qualche motivo configurato che il metodo sopra è rotto, posso suggerire un altro metodo di trasferimento file meno noioso, per accedere ai file root remoti.
Metodo Ninja Port Forward :
Accedere all'host remoto, ma specificare che la porta remota 3022 (può essere qualsiasi cosa libera e non riservata agli amministratori, ovvero> 1024) deve essere inoltrata di nuovo alla porta 22 sul lato locale.
[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
------------------------------------------------------------------------
Radica come di consueto ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Ora puoi scp i file nell'altra direzione evitando la noiosa fase noiosa di fare una copia intermedia dei file;
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Problema 2: inoltro dell'agente SSH : se si carica il profilo radice, ad esempio specificando una shell di accesso, le variabili di ambiente necessarie per l'inoltro dell'agente SSH, come ad esempio SSH_AUTH_SOCKvengono ripristinate, pertanto l'inoltro dell'agente SSH viene "interrotto" in sudo su -.
Risposta a metà cottura :
Tutto ciò che carica correttamente una shell di root reimposterà correttamente l'ambiente, tuttavia c'è un leggero accorgimento che puoi usare quando hai bisogno di ENTRAMBI i permessi di root E la possibilità di usare l'agente SSH, ALLO STESSO TEMPO
Ciò consente di ottenere una sorta di profilo chimera, che in realtà non deve essere utilizzato, poiché è un brutto hack , ma è utile quando è necessario eseguire il SCP dei file dall'host remoto come root, ad alcuni altri host remoti.
Ad ogni modo, puoi abilitare il tuo utente a preservare le sue variabili ENV, impostando quanto segue in sudoers;
Defaults:userXXX !env_reset
questo ti permette di creare cattivi ambienti di login ibridi in questo modo;
accedi 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
creare una shell bash, che viene eseguita /root/.profilee /root/.bashrc. ma conservaSSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Quindi questa shell ha i permessi di root e root $PATH(ma una home directory 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
Ma puoi usare quell'invocazione per fare cose che richiedono sudo root remoto, ma anche l'accesso dell'agente SSH in questo modo;
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#
-obandiera nellauseraddpagina del manuale. Questo flag è lì per consentire a più utenti di condividere lo stesso uid.