Что касается 3-й предложенной стратегии, кроме прочтения useradd -o -u userXXXопций, рекомендованных @jlliagre, я не знаком с несколькими пользователями, использующими один и тот же uid. (следовательно, если вы продолжите в том же духе, мне было бы интересно, если бы вы могли обновить пост с любыми проблемами (или успехами), которые возникают ...)
Полагаю, мое первое замечание, касающееся первого варианта «Открытый ключ каждого SSH помещен в ~ root / .ssh / авторизованный_кейс2», заключается в том, что если вы абсолютно никогда не собираетесь работать на каких-либо других системах;
- тогда, по крайней мере, иногда вам придется работать с учетными записями пользователей и
sudo
Вторым наблюдением будет то, что если вы работаете с системами, которые стремятся к HIPAA, PCI-DSS-совместимости или такими вещами, как CAPP и EAL, то вам придется работать над проблемами sudo, потому что;
- Это отраслевой стандарт для предоставления индивидуальных учетных записей пользователей без полномочий root, которые могут быть проверены, отключены, просрочены и т. Д., Обычно с использованием некоторой централизованной базы данных пользователей.
Так; Использование персонализированных аккаунтов и sudo
К сожалению, как системный администратор, почти все, что вам нужно будет сделать на удаленной машине, потребует некоторых повышенных разрешений, однако досадно, что большинство инструментов и утилит на основе SSH отключаются, пока вы находитесь в sudo
Поэтому я могу передать некоторые уловки, которые я использую, чтобы обойти раздражения, sudoкоторые вы упоминаете. Первая проблема заключается в том, что если вход в систему root заблокирован с помощью PermitRootLogin=noили у вас нет root с использованием ключа ssh, то это делает файлы SCP чем-то вроде PITA.
Проблема 1 : Вы хотите scp файлы с удаленной стороны, но они требуют root-доступа, однако вы не можете войти в удаленный ящик как root напрямую.
Скучное решение : скопируйте файлы в домашнюю директорию, chown и scp down.
ssh userXXX@remotesystem, sudo su -etc, cp /etc/somefilesto /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesиспользуйте scp для извлечения файлов с удаленного компьютера.
Очень скучно на самом деле.
Менее скучное решение : 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-файлы с удаленного хоста с правами суперпользователя на другой удаленный хост.
В любом случае, вы можете включить, чтобы ваш пользователь мог сохранять свои переменные 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(но домашний каталог 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
Но вы можете использовать этот вызов для выполнения задач, требующих удаленного root-доступа 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.