Berkenaan dengan strategi yang disarankan ke-3, selain teliti useradd -o -u userXXXopsi seperti yang direkomendasikan oleh @jlliagre, saya tidak akrab dengan menjalankan beberapa pengguna sebagai uid yang sama. (karenanya jika Anda melanjutkannya, saya akan tertarik jika Anda dapat memperbarui pos dengan masalah apa pun (atau berhasil) yang muncul ...)
Saya kira pengamatan pertama saya mengenai opsi pertama "Kunci publik SSH Semua orang dimasukkan ke dalam ~ root / .ssh / official_keys2", adalah bahwa kecuali Anda benar-benar tidak akan pernah bekerja pada sistem lain;
- lalu setidaknya beberapa waktu , Anda harus bekerja dengan akun pengguna dan
sudo
Pengamatan kedua adalah, bahwa jika Anda bekerja pada sistem yang bercita-cita untuk HIPAA, kepatuhan PCI-DSS, atau hal-hal seperti CAPP dan EAL, maka Anda harus mengatasi masalah sudo karena;
- Ini merupakan standar industri untuk menyediakan akun pengguna individu non-root, yang dapat diaudit, dinonaktifkan, kedaluwarsa, dll, biasanya menggunakan beberapa basis data pengguna terpusat.
Begitu; Menggunakan akun dan sudo yang dipersonalisasi
Sangat disayangkan bahwa sebagai sysadmin, hampir semua yang perlu Anda lakukan pada mesin jarak jauh akan memerlukan beberapa izin tinggi, namun itu menjengkelkan bahwa sebagian besar alat dan utilitas berbasis SSH rusak saat Anda berada di sudo
Karenanya saya dapat menyampaikan beberapa trik yang saya gunakan untuk mengatasi gangguan sudoyang Anda sebutkan. Masalah pertama adalah bahwa jika login root diblokir menggunakan PermitRootLogin=noatau Anda tidak memiliki root menggunakan kunci ssh, maka itu membuat file SCP sesuatu dari PITA.
Masalah 1 : Anda ingin scp file dari sisi jarak jauh, tetapi mereka membutuhkan akses root, namun Anda tidak dapat masuk ke kotak jauh sebagai root secara langsung.
Solusi Membosankan : salin file ke direktori home, chown, dan scp down.
ssh userXXX@remotesystem, sudo su -dll, cp /etc/somefileske /home/userXXX/somefiles,, chown -R userXXX /home/userXXX/somefilesgunakan scp untuk mengambil file dari jarak jauh.
Memang sangat membosankan.
Solusi Kurang Membosankan : sftp mendukung -s sftp_serverflag, maka Anda dapat melakukan sesuatu seperti berikut (jika Anda telah mengkonfigurasi sudo tanpa kata sandi di /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(Anda juga dapat menggunakan hack-around ini dengan sshfs, tapi saya tidak yakin ini direkomendasikan ... ;-)
Jika Anda tidak memiliki hak sudo tanpa kata sandi, atau karena alasan terkonfigurasi bahwa metode di atas rusak, saya dapat menyarankan satu lagi metode transfer file yang lebih tidak membosankan, untuk mengakses file root jarak jauh.
Metode Ninja Penerusan Port :
Login ke host jarak jauh, tetapi tentukan bahwa port jarak jauh 3022 (dapat berupa apa saja gratis, dan tidak disediakan untuk admin, yaitu> 1024) harus diteruskan kembali ke port 22 di sisi lokal.
[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
------------------------------------------------------------------------
Dapatkan root dengan cara normal ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Sekarang Anda dapat scp file ke arah lain menghindari langkah membosankan membosankan membuat salinan menengah file;
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Masalah 2: Penerusan agen SSH : Jika Anda memuat profil root, misalnya dengan menentukan shell login, variabel lingkungan yang diperlukan untuk penerusan agen SSH seperti SSH_AUTH_SOCKdiatur ulang, maka penerusan agen SSH "rusak" di bawah sudo su -.
Setengah jawaban panggang :
Apa pun yang memuat shell root dengan benar, akan mengatur ulang lingkungan dengan benar, namun ada sedikit penyelesaian yang dapat Anda gunakan saat Anda membutuhkan KEDUA root root DAN kemampuan untuk menggunakan Agen SSH, PADA SAAT YANG SAMA
Ini mencapai semacam profil chimera, yang seharusnya benar-benar tidak digunakan, karena ini adalah peretasan yang tidak menyenangkan , tetapi berguna ketika Anda perlu meng-SCP file dari host remote sebagai root, ke host remote lain.
Bagaimanapun, Anda dapat mengaktifkan bahwa pengguna Anda dapat mempertahankan variabel ENV mereka, dengan mengatur yang berikut ini dalam sudoers;
Defaults:userXXX !env_reset
ini memungkinkan Anda untuk membuat lingkungan login hybrid yang buruk seperti itu;
login seperti biasa;
[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
buat bash shell, yang berjalan /root/.profiledan /root/.bashrc. tapi mempertahankanSSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Jadi shell ini memiliki izin root, dan root $PATH(tetapi direktori home 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
Tetapi Anda dapat menggunakan doa itu untuk melakukan hal-hal yang memerlukan root sudo jarak jauh, tetapi juga akses agen SSH seperti itu;
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#
-obendera diuseraddhalaman buku panduan. Bendera ini ada untuk memungkinkan beberapa pengguna berbagi cairan yang sama.