Назад | Перейти на главную страницу

Получение настраиваемого .bashrc, доступного в сеансе ssh

В настоящее время у нас довольно много общий 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 чтобы увидеть места, где можно вставить пользовательскую среду при входе в систему. Процесс такой:

  1. напечатайте логин и motd, если tty или если не ~ / .hushlogin
  2. если войти на tty; записывает логин (обратите внимание, что LogLevel VERBOSE в sshd_config покажет ключ подключения, используемый для входа в систему
  3. если существует / etc / nologin, выйти
  4. изменить на запуск от имени обычного пользователя
  5. устанавливает базовую среду
  6. читает ~/.ssh/environment если PermitUserEnvironment установлен в sshd_config
  7. cd в домашний каталог пользователя
  8. если ~ / .ssh / rc существует, запускает его; иначе, если существует / etc / ssh / sshrc, запускает его ... (в основном для X11)
  9. запускает оболочку или команду пользователя.

Похоже, что использование ~ / .ssh / environment - лучший способ контролировать среду для каждого соединения. Однако, как предлагает Джейсон, это можно сделать, установив параметр среды в authorized_keys (если PermitUserEnvironment включен). Переменная среды USER может быть установлена ​​в это время для пользователя, отличного от пользователя, вошедшего в систему.

Переопределение USER (а оттуда и остальной части их среды) может быть лучшим подходом как с точки зрения ведения журнала на хосте, так и с точки зрения удобства подключения пользователей к нему.

К сожалению, сертификаты ssh (я не говорю об идентификационных ключах) не позволяют указывать переменные среды конкретно в сертификате подключения. Если бы это было предусмотрено, центр сертификации мог бы генерировать клиентские сертификаты со встроенными