Ssh SendEnv не работает при использовании с -J (хост перехода)?
Обновлено: подсказка для перезапуска ssh после редактирования /etc/ssh/sshd_config решила мою проблему (sudo systemctl restart ssh.service в Ubuntu), но см. принятый ответ для гораздо большего количества полезного устранения неполадок.
Оригинал:
У меня есть сервер, к которому я подключаюсь через хост перехода:
export MY_ENV=myvalue
ssh -o StrictHostKeyChecking=yes -o SendEnv=MY_ENV -J <myuser@jumpHostIp> <myuser@hostIp>
И хост перехода, и хост имеют в своем файле /etc/ssh/sshd_config:
AcceptEnv MY_ENV
И хост перехода, и хост имеют в своих /home/myuser/.ssh/authorized_keys ключ ssh, ограничивающий myuser сценарием развертывания:
command=/home/myuser/deploy.sh ...rest of public key...
Внутри этого deploy.sh я хотел бы использовать $MY_ENV, однако это не работает.
Сбрасывает ли использование узла перехода значение MY_ENV, переданное SendEnv? Если да, то это предназначено или как я могу получить доступ к значению MY_ENV в deploy.sh на хосте?
Ответы 1
Редактировать: я уточнил детали, рассматриваемые в процессе итерации, частично дублируя некоторые детали, уже названные в вопросе, для лучшего общего использования.
На справочной странице ssh указано:
Обратите внимание, что директивы конфигурации, указанные в командной строке, обычно применяются к целевому хосту, а не к каким-либо указанным хостам перехода. Используйте ~/.ssh/config, чтобы указать конфигурацию для узлов перехода.
Таким образом, ваш конечный пункт получит опции, добавленные -o. Поскольку параметры не затрагиваются хостом перехода, нет необходимости настраивать хост перехода для передачи переменных на хост назначения.
Конфигурация sshd на целевом сервере
В качестве предварительного условия служба sshd узла назначения должна быть настроена на прием переменной среды. Подстановочные знаки разрешены:
Файл: /etc/ssh/sshd_config
AcceptEnv MY_*
После изменения sshd_config необходимо перезапустить sshd, чтобы прочитать обновленную конфигурацию.
(решение этого вопроса...)
systemctl restart sshd
Текущее соединение сохранится при перезапуске sshd (по крайней мере, при использовании «openssh-server»
Ловушка в authorized_keys
Чтобы ограничить использование ключа в целевой системе, к авторизации можно добавить опцию.
Файл: authorized_keys с ограничением на команду
Вся аутентификация с помощью PublicKey завершится ошибкой, если опустить кавычки ", заключающие в себе значение параметра command:
command=/home/user/deploy.sh ssh-rsa AAAAB3NzaC1yc2EAA...
# DEBUG response of sshd:
debug1: /home/user/.ssh/authorized_keys:1: bad key options: missing start quote
В зависимости от настроек в sshd_config последует откат к аутентификации на основе пароля, соответственно, последует Permission denied (publickey)..
Кавычки " обязательны, даже если в команде нет пробела:
command = "/home/user/deploy.sh" ssh-rsa AAAAB3NzaC1yc2EAA...
Детали для команды клиента
Примечание. Помимо параметров командной строки, эти данные можно настроить у пользователя клиента ~/.ssh/config.
Для передачи желаемой переменной в качестве опции в командной строке возможны два варианта синтаксиса:
-o SendEnv=MY_ENV
-o "SendEnv MY_ENV"
Пожалуйста, не забывайте про цитаты ".
Существенным для доступности переменной является не только ее установка, но и ее экспорт:
Это не удастся:
MY_ENV = "Value"
echo $MY_ENV
Value
... несмотря на то, что переменная отображается в текущей оболочке.
Необходимый:
export MY_ENV = "Value"
В моей системе альтернативный синтаксис принимается так же, как и в вашей. — Вы ставили кавычки при подаче команды? — Они не включены в ваш комментарий, поэтому я заподозрил это.
Да, я использую «экспорт», и я использовал кавычки. Это не формат параметра. LC_MY_ENV проходит в обоих форматах. Каким-то образом все, что начинается с LC_*, проходит, а только MY_ENV без "LC_" - нет. Значит, должно быть какое-то другое место, кроме /etc/ssh/sshd_config, где я должен разрешить MY_ENV?
Хм, похоже, мне нужно получить тестовую конфигурацию. — Можно ли протестировать команду, запускающуюся с джампхоста (то есть тестировать конечный хост без промежуточного джампхоста)? — Было бы полезно снизить сложность отслеживания проблемы.
В качестве альтернативы: знаете ли вы о возможности определения переменных на целевом хосте в ~/.ssh/environment (в доме пользователя целевого хоста)? — Насколько это полезно, зависит от концепции вашего сценария.
Определение переменных на целевом хосте бесполезно, поскольку моя переменная задается извне лицом, выполняющим развертывание. Он сообщает deploy.sh, какую ветку нашего git-репозитория нужно развернуть. Я сделал тест без узла перехода (временно открывая вещи), и MY_ENV достигает сценария развертывания! Так что это что-то на хосте перехода или это связано с использованием хоста перехода. Спасибо за помощь, кстати!
Вы еще не упомянули: несмотря на проблему с MY_ENV, соединение ssh через jumphost успешно?
О да, deploy.sh выполняется также с хостом перехода. Там у меня есть «echo $MY_ENV» и другие тестовые команды, поэтому я знаю, что MY_ENV не достигает deploy.sh с хостом перехода.
Я уточнил свой ответ, так как мог проверить детали, настроив путь к хосту перехода. — В качестве почти тривиальной (но распространенной) ошибки: перезапускали ли вы свой sshd на целевом хосте после реконфигурации с помощью AcceptEnv MY_ENV?
Работает!! Я не знал, что вы должны перезапустить его. Спасибо за помощь! Я хотел бы принять ваш ответ, можете ли вы вставить большой жир «вам нужно перезапустить sshd, чтобы изменения вступили в силу» перед вашим ответом :)?
Ответ обновлен. Приятно слышать, что усилия увенчались успехом.
Альтернативный синтаксис не работает. Однако я заметил, что если я назову свою переменную среды LC_MY_ENV, она будет передана в deploy.sh (с -o SendEnv LC_MY_ENV)! Таким образом, это означает, что что-то блокирует переменную MY_ENV, хотя я добавил ее в /etc/ssh/sshd_config «AcceptEnv MY_ENV» как для узла перехода, так и для узла. У вас есть идея, что это может быть?