В настоящее время у нас довольно много общий ssh выполняет вход на различные серверы, и моим коллегам не понравилось бы, если бы я слишком много возился с оболочкой по умолчанию. Однако у меня есть целый список псевдонимов и пользовательских функций в моем .bashrc
что я хотел бы следовать за мной.
Кроме того, поскольку некоторые соединения могут быть сложными, первое, что мне нравится делать, - это запускать сеанс экрана, поэтому, если соединение снова откажется от меня, я могу просто войти в систему и продолжить движение туда, где я оставил.
В настоящее время я делаю это, добавляя довольно запутанную строку к своим логинам ssh:
ssh -t -l sharedname someserver.example.com 'if [ -z \`find ~ -maxdepth 1 -iname '.wrikken_bashrc.sh' -mtime -14 \` ]; then scp wrikken@wrikken.example.com:.bash_remote.sh ~/.wrikken_bashrc.sh; fi; screen -h 2000 -DR wrikken bash --rcfile ~/.wrikken_bashrc.sh'
Это работает удовлетворительно (конечно, мне никогда не нужно вводить его после того, как .bash_remote.sh
file), но я серьезно сомневаюсь, что это / правильное решение. Кроме того, иногда мне нужно вводить свой пароль, чтобы получить обновление .wrikken_bashrc.sh
файл, конечно, боль. К сожалению, личный аккаунт не подходит.
Короче говоря: есть ли лучший способ, чтобы мои пользовательские псевдонимы и функции следовали за мной через ssh-входы?
Наша команда использует аналогичную настройку на наших серверах разработки. Если нашим разработчикам нужно запускать команды для управления экземпляром сервера, они могут использовать нашу команду «предположить», которая является просто оболочкой для ssh. Рабочие серверы закрыты для разработчиков, если нам не нужно отлаживать что-то серьезное.
Каждый разработчик, авторизованный для входа в учетную запись экземпляра сервера, имеет запись в поле authorized_keys (Подробнее см. В разделе ФОРМАТ ФАЙЛА AUTHORIZED_KEYS.) файл, но каждый авторизованный ключ имеет флаг, который устанавливает переменную среды, уникальную для их имени пользователя:
environment="SSHUSER=jason" ssh-rsa (BASE64-ENCODED-KEY) jason@localhost
В этом экземпляре сервера .bashrc у меня есть небольшой фрагмент кода:
USERHOME=$(eval "echo ~$SSHUSER")
if [ -f "$USERHOME/.client_bashrc" ]; then
. "$USERHOME/.client_bashrc"
fi
Наши разработчики могут хранить файл .client_bashrc (отдельно от их .bashrc) с разрешениями на чтение в своем домашнем каталоге. Отделение их .bashrc от .client_bashrc помогает с безопасностью, поскольку они могут хранить частные определения и переменные среды в .bashrc. При желании они могут поместить строку кода в свой личный bashrc, чтобы просто включить .client_bashrc и сохранить там псевдонимы и определения, которые упрощают работу с системой. (Все это предполагает, что домашний каталог пользователя доступен с сервера разработки.)
Уорнер в своем комментарии подчеркивает, что такая установка общего имени пользователя противоречит лучшим практикам безопасности. Наша система произошла от учетной записи на общем хосте много лет назад. Мы только сейчас подходим к ограничению возможностей учетных записей разработчиков и переходим к системе, в которой действия разработчика записываются в журнал аудита.
Полезно просмотреть процесс входа в систему, описанный в man sshd
чтобы увидеть места, где можно вставить пользовательскую среду при входе в систему. Процесс такой:
~/.ssh/environment
если PermitUserEnvironment установлен в sshd_configПохоже, что использование ~ / .ssh / environment - лучший способ контролировать среду для каждого соединения. Однако, как предлагает Джейсон, это можно сделать, установив параметр среды в authorized_keys (если PermitUserEnvironment включен). Переменная среды USER может быть установлена в это время для пользователя, отличного от пользователя, вошедшего в систему.
Переопределение USER (а оттуда и остальной части их среды) может быть лучшим подходом как с точки зрения ведения журнала на хосте, так и с точки зрения удобства подключения пользователей к нему.
К сожалению, сертификаты ssh (я не говорю об идентификационных ключах) не позволяют указывать переменные среды конкретно в сертификате подключения. Если бы это было предусмотрено, центр сертификации мог бы генерировать клиентские сертификаты со встроенными