Що стосується третьої запропонованої стратегії, окрім ознайомлення з useradd -o -u userXXXпараметрами, рекомендованими @jlliagre, я не знайомий із тим, як запускати декілька користувачів як один і той же uid. (отже, якщо ви все-таки продовжуватимете це, я був би зацікавлений, якщо ви можете оновити публікацію з будь-якими проблемами (або успіхами), які виникають ...)
Я думаю, що моє перше зауваження щодо першого варіанту "публічний ключ SSH кожного вводиться в ~ root / .ssh / pooblasti_keys2", це те, що якщо ви абсолютно ніколи не будете працювати на інших системах;
- то принаймні деякий час вам доведеться працювати з обліковими записами користувачів і
sudo
Другим зауваженням було б те, що якщо ви працюєте в системах, які прагнуть до HIPAA, відповідності PCI-DSS, або таких предметів, як CAPP та EAL, вам доведеться вирішувати питання судо, тому що;
- Це галузевий стандарт для надання некореневих облікових записів користувачів, які можуть бути перевірені, відключені, закінчилися термін дії тощо, як правило, використовуючи деяку централізовану базу даних користувачів.
Так; Використання персоналізованих акаунтів та sudo
Прикро, що як системний адміністратор, майже все, що вам потрібно буде зробити на віддаленій машині, вимагатиме підвищених дозволів, однак прикро, що більшість інструментів та утиліт на базі SSH розбиті, коли ви знаходитесь в sudo
Отже, я можу передати деякі хитрощі, які використовую, щоб подолати роздратування sudoзгаданих вами причин. Перша проблема полягає в тому, що якщо кореневий вхід блокується за допомогою PermitRootLogin=noабо у вас немає кореня за допомогою ключа ssh, то це робить SCP файли чимось PITA.
Проблема 1 : Ви хочете скопіювати файли з віддаленої сторони, але вони потребують кореневого доступу, проте ви не можете увійти до віддаленого вікна як корінь безпосередньо.
Нудне рішення : скопіюйте файли в домашній каталог, затухайте та скапуйте.
ssh userXXX@remotesystem, І sudo su -т.д., cp /etc/somefilesщоб /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesвикористовуйте УПП для вилучення файлів з пульта дистанційного керування.
Дійсно дуже нудно.
Менш нудне рішення : sftp підтримує -s sftp_serverпрапор, отже, ви можете зробити щось на зразок наступного (якщо ви налаштували sudo без пароля /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(Ви також можете скористатися цим хак-файлом за допомогою sshfs, але я не впевнений, що його рекомендують ... ;-)
Якщо у вас немає прав на sudo, не захищені паролем, або з якоїсь сконфігурованої причини порушення методу вище, я можу запропонувати ще один менш нудний спосіб передачі файлів для доступу до віддалених кореневих файлів.
Метод ніндзя вперед :
Увійдіть до віддаленого хоста, але вкажіть, що віддалений порт 3022 (може бути будь-яким безкоштовним та незарезервованим для адміністраторів, тобто> 1024) повинен бути перенаправлений назад до порту 22 на локальній стороні.
[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
------------------------------------------------------------------------
Отримайте корінь звичайним способом ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Тепер ви можете пропрасувати файли в іншому напрямку, уникаючи нудного нудного кроку зробити проміжну копію файлів;
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Проблема 2: Переадресація агента SSH : Якщо ви завантажуєте кореневий профіль, наприклад, вказуючи оболонку входу, необхідні змінні середовища для переадресації агента SSH, такі як SSH_AUTH_SOCKскидання, отже, переадресація агента SSH буде "зламана" під sudo su -.
Напівзапекла відповідь :
Все, що належним чином завантажує кореневу оболонку, буде належним чином скинути середовище, однак є невелика робота, яку можна використовувати, коли вам потрібно ДОСТУПНИЙ корінний дозвіл І можливість користуватися агентом SSH, В ОДНІЙ ЧАС
Це досягає свого роду химерного профілю, який насправді не слід використовувати, оскільки це неприємний злом , але корисний, коли вам потрібно передавати файли SCP з віддаленого хоста як root, на якийсь інший віддалений хост.
У будь-якому випадку, ви можете увімкнути, що ваш користувач може зберегти свої ENV-змінні, встановивши наступне в sudoers;
Defaults:userXXX !env_reset
це дозволяє створювати неприємні гібридні середовища входу на зразок цього;
вхід як звичайний;
[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
створити bash оболонку, яка працює /root/.profileі /root/.bashrc. але зберігаєSSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Таким чином, ця оболонка має права доступу до root та root $PATH(але домашній каталог із захищеним файлом ...)
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
Але ви можете використовувати це виклик, щоб робити речі, для яких потрібен віддалений корінь sudo, але також доступ до 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#
-oпрапор наuseraddсторінці керівництва. Цей прапор існує для того, щоб дозволити декільком користувачам обмінюватися одним і тим же uid.