Jeśli chodzi o trzecią sugerowaną strategię, inną niż useradd -o -u userXXXprzejrzenie opcji zalecanych przez @jlliagre, nie jestem zaznajomiony z obsługą wielu użytkowników jako tego samego identyfikatora użytkownika. (dlatego jeśli to zrobisz, byłbym zainteresowany, gdybyś mógł zaktualizować post o pojawiające się problemy (lub sukcesy) ...)
Wydaje mi się, że moje pierwsze spostrzeżenie dotyczące pierwszej opcji „Klucz publiczny SSH dla każdego jest umieszczony w katalogu ~ root / .ssh / author_keys2”, jest taki, że chyba, że absolutnie nigdy nie będziesz pracować na żadnym innym systemie;
- przynajmniej przez jakiś czas będziesz musiał pracować z kontami użytkowników i
sudo
Drugim spostrzeżeniem byłoby to, że jeśli pracujesz na systemach, które aspirują do HIPAA, zgodności z PCI-DSS lub takich rzeczy jak CAPP i EAL, będziesz musiał obejść problemy sudo, ponieważ;
- Jest to standard branżowy zapewniający konta użytkowników innych niż root, które mogą być kontrolowane, wyłączane, wygasają itp., Zwykle przy użyciu scentralizowanej bazy danych użytkowników.
Więc; Korzystanie ze spersonalizowanych kont i sudo
To niefortunne, że jako administrator systemu prawie wszystko, co musisz zrobić na zdalnej maszynie, będzie wymagało pewnych podwyższonych uprawnień, jednak denerwujące jest to, że większość narzędzi i narzędzi opartych na SSH została zablokowana, gdy jesteś w sudo
Dlatego mogę przekazać pewne sztuczki, których używam, aby obejść irytujące sudowspomnienia, o których wspomniałeś. Pierwszy problem polega na tym, że jeśli logowanie użytkownika root jest zablokowane za pomocą PermitRootLogin=nolub nie masz konta root za pomocą klucza ssh, to powoduje, że pliki SCP są czymś w rodzaju PITA.
Problem 1 : Chcesz scpować pliki ze strony zdalnej, ale wymagają one dostępu do konta root, jednak nie możesz zalogować się do zdalnej skrzynki jako root.
Nudne rozwiązanie : skopiuj pliki do katalogu domowego, zmień i scp w dół.
ssh userXXX@remotesystem, sudo su -itp., cp /etc/somefilesdo /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesużyj scp do pobrania plików ze zdalnego.
Rzeczywiście bardzo nudne.
Mniej nudne rozwiązanie : sftp obsługuje -s sftp_serverflagę, dlatego możesz wykonać następujące czynności (jeśli skonfigurowałeś sudo bez hasła /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(możesz również użyć tego hack-around z sshfs, ale nie jestem pewien, czy jest to zalecane ... ;-)
Jeśli nie masz praw do hasła sudo bez hasła lub z jakiegoś skonfigurowanego powodu powyższa metoda jest zepsuta, mogę zasugerować jeszcze jedną nudną metodę przesyłania plików, aby uzyskać dostęp do zdalnych plików root.
Metoda Port Forward Ninja :
Zaloguj się do zdalnego hosta, ale określ, że zdalny port 3022 (może być dowolny wolny i niezastrzeżony dla administratorów, tj.> 1024) ma być przekierowany z powrotem do portu 22 po stronie lokalnej.
[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
------------------------------------------------------------------------
Zrootuj się w normalny sposób ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Teraz możesz scpować pliki w innym kierunku, unikając nudnego, nudnego kroku tworzenia pośredniej kopii plików;
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Problem 2: Przekazywanie agenta SSH : Jeśli załadujesz profil główny, np. Poprzez określenie powłoki logowania, niezbędne zmienne środowiskowe dla przekazywania agenta SSH, takie jak SSH_AUTH_SOCKsą resetowane, dlatego przekazywanie agenta SSH jest „zepsute” sudo su -.
Połowa upieczonej odpowiedzi :
Wszystko, co poprawnie ładuje powłokę roota, słusznie zresetuje środowisko, jednak istnieje pewne obejście, którego możesz użyć, gdy potrzebujesz OBOWIĄZKOWEGO uprawnienia roota I możliwości korzystania z agenta SSH, W TYM SAMYM CZASIE
Osiąga to rodzaj profilu chimery, którego tak naprawdę nie należy używać, ponieważ jest to paskudny hack , ale jest użyteczny, gdy trzeba przesyłać pliki SCP ze zdalnego hosta jako root do innego zdalnego hosta.
W każdym razie możesz włączyć możliwość zachowania przez użytkownika zmiennych ENV, ustawiając następujące opcje w sudoers;
Defaults:userXXX !env_reset
pozwala to na tworzenie nieprzyjemnych hybrydowych środowisk logowania;
zaloguj się jak zwykle;
[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
utwórz powłokę bash, która działa /root/.profilei /root/.bashrc. ale zachowujeSSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Ta powłoka ma uprawnienia roota i root $PATH(ale zepsuty katalog domowy ...)
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
Ale możesz użyć tego wywołania, aby wykonać czynności wymagające zdalnego rootowania sudo, ale także dostępu agenta SSH;
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#
-oflagę nauseraddstronie podręcznika. Ta flaga umożliwia wielu użytkownikom współużytkowanie tego samego identyfikatora użytkownika.