Đối với chiến lược được đề xuất thứ 3, ngoài việc sử dụng các useradd -o -u userXXXtùy chọn theo khuyến nghị của @jlliagre, tôi không quen với việc chạy nhiều người dùng như một uid. (do đó nếu bạn tiếp tục với điều đó, tôi sẽ quan tâm nếu bạn có thể cập nhật bài đăng với bất kỳ vấn đề nào (hoặc thành công) phát sinh ...)
Tôi đoán quan sát đầu tiên của tôi về tùy chọn đầu tiên "Khóa công khai SSH của mọi người được đưa vào ~ root / .ssh / ủy quyền_keys2", trừ khi bạn hoàn toàn không bao giờ hoạt động trên bất kỳ hệ thống nào khác;
- sau đó ít nhất một thời gian , bạn sẽ phải làm việc với tài khoản người dùng và
sudo
Quan sát thứ hai sẽ là, nếu bạn làm việc trên các hệ thống mong muốn tuân thủ HIPAA, PCI-DSS hoặc các công cụ như CAPP và EAL, thì bạn sẽ phải giải quyết các vấn đề về sudo bởi vì;
- Đó là một tiêu chuẩn công nghiệp để cung cấp các tài khoản người dùng không phải root, có thể được kiểm toán, vô hiệu hóa, hết hạn, v.v., thường sử dụng một số cơ sở dữ liệu người dùng tập trung.
Vì thế; Sử dụng tài khoản cá nhân và sudo
Thật không may là là một sysadmin, hầu hết mọi thứ bạn cần làm trên một máy từ xa sẽ yêu cầu một số quyền nâng cao, tuy nhiên thật khó chịu khi hầu hết các công cụ và tiện ích dựa trên SSH đều bị hỏng trong khi bạn đang ở trong sudo
Do đó tôi có thể chuyển qua một số thủ thuật mà tôi sử dụng để khắc phục những phiền toái sudomà bạn đề cập. Vấn đề đầu tiên là nếu đăng nhập root bị chặn bằng cách sử dụng PermitRootLogin=nohoặc bạn không có root bằng khóa ssh, thì nó sẽ tạo cho các tệp SCP một cái gì đó của PITA.
Vấn đề 1 : Bạn muốn quét các tập tin từ phía từ xa, nhưng chúng yêu cầu quyền truy cập root, tuy nhiên bạn không thể đăng nhập vào hộp từ xa dưới dạng root trực tiếp.
Bored Solution : sao chép các tập tin vào thư mục chính, chown và scp xuống.
ssh userXXX@remotesystem, sudo su -Vv, cp /etc/somefilesđể /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefiles, sử dụng scp để lấy các tập tin từ xa.
Thực sự rất nhàm chán.
Giải pháp ít nhàm chán hơn : sftp hỗ trợ -s sftp_servercờ, do đó bạn có thể thực hiện một số thao tác như sau (nếu bạn đã cấu hình sudo in mật khẩu /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(bạn cũng có thể sử dụng hack-around này với sshfs, nhưng tôi không chắc nó được khuyến nghị ... ;-)
Nếu bạn không có quyền sudo không có mật khẩu hoặc vì một số lý do được định cấu hình mà phương thức trên bị hỏng, tôi có thể đề xuất một phương thức truyền tệp ít nhàm chán hơn, để truy cập các tệp gốc từ xa.
Phương pháp chuyển tiếp cổng Ninja :
Đăng nhập vào máy chủ từ xa, nhưng xác định rằng cổng từ xa 3022 (có thể là bất cứ thứ gì miễn phí và không dành riêng cho quản trị viên, tức là> 1024) sẽ được chuyển tiếp về cổng 22 ở phía cục bộ.
[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
------------------------------------------------------------------------
Bắt nguồn từ thời trang bình thường ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Bây giờ bạn có thể quét các tệp theo hướng khác để tránh bước nhàm chán nhàm chán khi tạo một bản sao trung gian của các tệp;
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Vấn đề 2: Chuyển tiếp tác nhân SSH : Nếu bạn tải cấu hình gốc, ví dụ: bằng cách chỉ định shell đăng nhập, các biến môi trường cần thiết để chuyển tiếp tác nhân SSH như SSH_AUTH_SOCKđược đặt lại, do đó chuyển tiếp tác nhân SSH bị "hỏng" bên dưới sudo su -.
Câu trả lời nửa nướng :
Bất cứ điều gì tải vỏ gốc đúng cách, sẽ thiết lập lại môi trường một cách hợp lý, tuy nhiên có một chút công việc bạn có thể sử dụng khi bạn cần quyền BÓNG gốc và khả năng sử dụng Tác nhân SSH, TRONG THỜI GIAN CÙNG
Điều này đạt được một loại hồ sơ chimera, thực sự không nên được sử dụng, bởi vì nó là một hack khó chịu , nhưng rất hữu ích khi bạn cần các tệp SCP từ máy chủ từ xa như root, đến một số máy chủ từ xa khác.
Dù sao, bạn có thể cho phép người dùng của bạn có thể bảo tồn các biến ENV của họ, bằng cách đặt các mục sau trong sudoers;
Defaults:userXXX !env_reset
điều này cho phép bạn tạo ra các môi trường đăng nhập lai khó chịu như vậy;
đăng nhập như bình thường;
[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
tạo một vỏ bash, chạy /root/.profilevà /root/.bashrc. nhưng bảo quảnSSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Vì vậy, shell này có quyền root và root $PATH(nhưng một thư mục 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
Nhưng bạn có thể sử dụng lời mời đó để thực hiện những việc yêu cầu root sudo từ xa, nhưng cũng có quyền truy cập tác nhân SSH như vậy;
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#
-ocờ tronguseraddtrang hướng dẫn. Cờ này ở đó để cho phép nhiều người dùng chia sẻ cùng một uid.