Önerilen 3. stratejiyle ilgili olarak, useradd -o -u userXXXjlliagre tarafından önerilen seçeneklerin algılanması dışında, aynı kullanıcı olarak birden fazla kullanıcı çalıştırmaya aşina değilim. (bu nedenle devam ederseniz, yayını herhangi bir sorunla (veya başarılarla) güncelleyebilseydiniz, ilgilenirim ...)
Sanırım ilk seçenek olan "Herkesin SSH ortak anahtarı ~ root / .ssh / onay_2_2 anahtarına yerleştirildi" konusuna olan ilk gözlemim, kesinlikle başka hiçbir sistemde çalışmayacağınız sürece;
- o zaman en azından bir süre , kullanıcı hesaplarıyla çalışmak zorunda kalacaksınız ve
sudo
İkinci gözlem, eğer HIPAA, PCI-DSS uyumluluğunu ya da CAPP ve EAL gibi şeyleri isteyen sistemler üzerinde çalışıyorsanız, o zaman sudo sorunları üzerinde çalışmak zorunda kalacaksınız;
- Bu bir endüstri standardı kök olmayan bireysel kullanıcı hesaplarını temin etmek, yani tipik bazı merkezi kullanıcı veritabanı kullanılarak, vb, zaman aşımına uğramış engelli, denetlenebilir.
Yani; Kişiselleştirilmiş hesapları ve sudo kullanımı
Bir sysadmin olarak, uzak bir makinede yapmanız gereken hemen hemen her şeyin bazı yüksek izinlere ihtiyaç duyması talihsiz bir durumdur; sudo
Dolayısıyla, sudobahsettiğiniz sıkıntıları gidermek için kullandığım bazı püf noktalarını üzerinden geçebilirim . İlk sorun, kök girişinin kullanımı engelleniyorsa PermitRootLogin=noveya ssh anahtarını kullanarak kökünüz yoksa, SCP dosyalarına bir PITA işlevi yapar.
Sorun 1 : Dosyaları uzak taraftan taramak istiyorsunuz ancak kök erişimi gerekiyor, ancak uzak kutuya doğrudan kök olarak giriş yapamazsınız.
Sıkıcı Çözüm : dosyaları ana dizine kopyalayın, kopyalayın ve kopyalayın.
ssh userXXX@remotesystem, sudo su -etc, cp /etc/somefilesto /home/userXXX/somefiles,, chown -R userXXX /home/userXXX/somefilesuzaktaki dosyaları almak için scp kullanın.
Gerçekten çok sıkıcı.
Daha Az Sıkıcı Çözüm : sftp -s sftp_serverbayrağı destekler , bu nedenle aşağıdaki gibi bir şey yapabilirsiniz (eğer parolasız sudo girişi yapılandırdıysanız /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(sshfs ile bu hack-etrafında da kullanabilirsiniz, ancak onun tavsiye edildiğinden emin değilim ... ;-)
Parola içermeyen sudo haklarınız yoksa veya yukarıdaki bu yöntemin bozulması nedeniyle yapılandırılmış bir nedenden dolayı, uzak kök dosyalara erişmek için bir daha az sıkıcı dosya aktarma yöntemi önerebilirim.
Port İleri Ninja Yöntemi :
Uzak ana bilgisayara giriş yapın, ancak 3022 nolu uzak bağlantı noktasının (ücretsiz bir şey olabilir ve yöneticiler için ayrılmış, yani> 1024 olabilir) yerel taraftaki 22 numaralı bağlantı noktasına geri gönderileceğini belirtin.
[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
------------------------------------------------------------------------
Normal şekilde kök salın ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Artık dosyaların bir orta kopyasını çıkarmak için sıkıcı sıkıcı adımdan kaçınarak dosyaları başka bir yöne doğru tarayabilirsiniz;
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Sorun 2: SSH ajanı iletme : Kök profilini yüklerseniz, örneğin bir oturum açma kabuğu belirleyerek, SSH ajanı iletimi için gerekli ortam değişkenleri SSH_AUTH_SOCKsıfırlanır, dolayısıyla SSH ajanı iletimi "bozulur" sudo su -.
Yarı pişmiş cevap :
Düzgün bir kök kabuğu yükler şey, haklı çevreyi sıfırlamak için gidiyor, ancak hafif bir iş çevresinde var olan senin teneke kullanımı sen, HEM kök izni VE SSH Ajan kullanma olanağı gerektiğinde AYNI ZAMANDA
Bu, gerçekten kullanılmaması gereken bir tür chimera profili elde eder, çünkü kötü bir kesektir , ancak uzak ana bilgisayardan root olarak SCP dosyalarına ya da başka bir uzak ana bilgisayara SCP dosyaları gerektiğinde kullanışlıdır.
Her neyse, aşağıdakileri sudo'larda ayarlayarak, kullanıcının ENV değişkenlerini koruyabilmesini sağlayabilirsiniz;
Defaults:userXXX !env_reset
Bu, böyle kötü melez giriş ortamları yaratmanıza izin verir;
normal giriş yapın;
[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
/root/.profileve çalıştıran bir bash kabuğu oluşturun /root/.bashrc. ama korurSSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Öyleyse bu kabuğun kök izinleri ve kökleri var $PATH(fakat bir giriş dizini ...)
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
Ancak bu çağrıyı, uzak sudo kökü gerektiren şeyleri yapmak için de kullanabilirsiniz; aynı zamanda SSH ajanı erişimi de öyle;
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#
-obayrağa bir göz atınuseradd. Bu bayrak, aynı kullanıcının kimliği paylaşan birden fazla kullanıcıya izin vermek için vardır.