1

Предположим, у меня есть следующий сеанс SSH:

userA@boxA -> userB@boxB -> userC@boxC

Теперь из boxC , как userC , я хотел бы получить информацию о том, что ssh-соединение пришло от userB@boxB которое, в свою очередь, от userA@boxA .

Теперь у меня есть следующий сеанс SSH вместе с первым сеансом SSH:

userD@boxD -> userB@boxB

из boxB , как userB , я хотел бы получить информацию о том, что соединение пришло от userD@boxD и что существует второй ssh-сеанс от userA@boxA .

эта информация доступна и доступна как пользователь? это вообще доступно?

если нет, есть ли какой-нибудь "простой" способ сделать эту информацию доступной? с легким, я имею в виду без взлома и перекомпиляции sshd, и без необходимости иметь root-доступ на машинах.

4 ответа4

2

Официальный способ отправки переменных среды с клиента на сервер - через SendEnv и AcceptEnv . Проблема в том, что вам нужен root-доступ на сервере для настройки AcceptEnv . Большинство серверов сконфигурированы так, чтобы не принимать никаких или только несколько предопределенных переменных.

Я нашел две хитрости для отправки переменных среды от клиента к серверу, оба работают без необходимости root-доступа на сервере.

хитрость первая:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME bash

он подключится к серверу и затем выполнит команду SSH_ORIGIN=$USERNAME@$HOSTNAME bash с уже замененными $USERNAME и $HOSTNAME на стороне клиента. затем на стороне сервера вы можете дополнительно обработать информацию, содержащуюся в переменной SSH_ORIGIN .

-t необходим, иначе bash будет запущен на сервере без tty (попробуйте, вы увидите).

небольшая модификация позволит транзитивно передавать информацию по более длинной цепочке ssh.

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN bash

обсуждение:

  • bash запускается как интерактивная оболочка без авторизации (.profile не читается).
  • bash запускается дважды (.bashrc читается дважды). один раз по sshd и один раз по команде пользователя.
  • он всегда запускает bash, игнорируя оболочку по умолчанию на сервере.

трюк второй:

сначала вы должны сгенерировать ключ ssh и передать его в ~/.ssh/authorized_keys на сервере. затем добавьте строку с command="$SHELL" . см. справочную страницу sshd для получения дополнительной информации об этом.

подключиться к ssh серверу с помощью команды:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME

это соединится с сервером, но на этот раз присвоение переменной не выполняется. вместо этого строка сохраняется в переменной среды $SSH_ORIGINAL_COMMAND . затем выполняется команда, указанная в ~/.ssh/authorized_keys . как только вы попали в оболочку, вы можете обрабатывать информацию, содержащуюся в $SSH_ORIGINAL_COMMAND .

как указано выше, вы можете сделать это переходным:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN

обсуждение:

  • он запустит оболочку по умолчанию на сервере.
  • он всегда запускает оболочку по умолчанию на сервере. любая команда, которую вы дадите команде ssh, будет проигнорирована и сохранена в $SSH_ORIGINAL_COMMAND . если вы хотите выполнить команду через ssh, вы можете использовать другой ключ ssh или иметь свой файл инициализации оболочки для обнаружения и выполнения $SSH_ORIGINAL_COMMAND .
1

Я думаю, что вы могли бы заставить переменную среды на hostB написать адрес hostA. Затем на hostC используйте AcceptEnv для получения окружения от hostB, вуаля :)

прочитайте немного sshd_config, части относительно окружающей среды.

1

Команда, who сообщает вам, кто еще вошел в систему сейчас на той же машине и откуда они вошли. Команда last дает ту же информацию для прошлых сеансов. В зависимости от конфигурации компьютера и методов входа в систему информация может не всегда быть полной, актуальной или доступной для пользователей без полномочий root.

В вашем сценарии A @ A-> B @ B-> C @ C невозможно из машины C узнать, что B @ B был зарегистрирован в B через сеанс ssh от A. В 1980-х, когда все доверяли всем, вы мог бы попробовать finger или ident , но в эти дни машина B вряд ли будет даже запускать finger или идент.

0

Из блока C без доступа к блоку B вы не сможете сказать, что пользователь пришел из блока A. На самом деле вы не сможете определить, как пользователь попал в блок C. Это просто зависит от того, как Администратор настроил вещи.

Тот же ответ на вопрос «предположим, что дальше». Это зависит от разрешений, предоставленных системным администратором, и программ, которые он или она установили.

Соответствующие команды, которые могут помочь вам, если у вас есть разрешения (но, вероятно, нет):

finger - http://www.manpagez.com/man/1/finger/

last - http://www.manpagez.com/man/1/last/

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .